Keywords Flashcards
1
Q
Devil’s/iron triangle/triple constraints
A
Ensure that software is delivered
- On time
- Within budget
- In accordance with the requirements (scope)
(Quality could be added)
They are connected to each other: More requirements = more time needed = more budget needed
2
Q
Agile manifesto
A
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
3
Q
Why is developing IT for government hard? (Elias Committee)
A
- National government is not ‘in control’ regarding ICT projects
- Politicians do not realize, but ICT is everywhere
o Almost all solutions require ICT, but they don’t plan for it - National government does not fulfill her ICT policy objectives
- The accountability and decision making structure is deficient
o Difficult who made what decision at what timepoint. There should be an additional oversight (ICT chamber), projects are killed by this oversight board - Government has insufficient insight in costs and benefits of ICT
o Very difficult and complex - ICT knowledge of the national government is lacking
o Some specialists, but they are typically rare or hired (consultancy firms). So the governments themselves don’t actually learn - ICT project management is weak
- ICT bid-for-tender procedures contain perverse incentives
o Most of the times the lowest cost wins the tender, which could make it less quality/ambitions. Then it has to be made bigger during the project - Management of contracts in ICT-projects is not professional
o The negotiation and checking of the other party complies to the contract isn’t done very well - National government lacks the necessary learning ability
o Not learning from mistakes. Can be done by installing an expertise center for ICT (the same as you have Rijkswaterstaat who is dedicated to the traffic/infrastructure)
There is no strong dialogue between the government and the (software) outside parties. Agile does try to enhance communication
Recommendations:
- 2. Demonstrate added value of project for end users and for society
o Not always clear (what’s in it for the stakeholders?)
- 3. Create support among all parties involved, including end-users, and test for organizational (does in fit the governance structure?), administrational (does it fit the administry?) and technical (does it connect to existing systems?) feasibility
- 10. Make use of a transparent bid-for-tender strategy in the business justification of a project, Project Initiation Document (PID): provides the foundation for the business project
o Make functional specification compulsory, or explain why not. Specific technical details are left to the provider
4
Q
What are the characteristics of the Waterfall method?
A
Analysis - Design - Implement - Test - Adoption - Maintenance and Usage
- Hardly any company uses this anymore. Originated in the military to plan large logistics operations.
- Output of one phase flows in to the next phase.
- Managers like this because it is clear where you can draw the line/where it begins and ends. They can create results/milestones
- It has clear boundaries and deliverables
- Implement: Coding by a programmer
- Adoption: Testing is the last phase a developer will do. Then it will go into the organization who wants the software. Adoption is quite a long stage. Even if the software is good, it could not satisfy the needs of the client
5
Q
What are the characteristics of the SDLC method?
A
System Analysis - Conceptual Design - Physical Design - Implementation and Conversion - Operation and Maintenance
- Iterative process
- There are a lot of libraries with software, you can probably pick some parts of those out for your own software, instead of starting from scratch
- Implement: Showing it to end-users, training them and conversion of data from old to new software
- 3 things in the middle (Feasability analysis, decision making, (re)planning): These have to be done in every step in the process
6
Q
What are the characteristics of the Spiral model? (Boehm, 1998)
A
Analysis - Design - Implementation - Testing
- Sort of an Agile process. But these steps are normally longer (6 months)
- Iterative: timebox periods
o Set a time limit for a circle. So you will focus on the important things because you have to deliver something after 6 months e.g. Because most of the times the project will keep going on and on until time is up/deadline
- Risk management: drives decision making –> Risk considerations shape the (type of) process/model
- Various cycles: learn and improve
- Importance of validation and testing
- Concept of operation: Has to be validated by experts before being able to get to the next phase
7
Q
What are the principles of Agile (Agile Manifesto)
A
Software development is a social process (focus on people)
- Satisfy customer
- Welcome change in requirements
- Deliver frequently
- Business and developers work together
- Facilitate motivated people to do their jobs
- Face-to-face communication
- Working software is the measure for progress
- Attention to technical excellence
• Make sure you can retain (technical) specialists by rewarding, providing interesting projects etc. - Simplicity
• Break things up in small parts that can be solved one by one - Self-organizing teams
• Help each other, no need for external managers, Agile specialist is part of the team - Teams evaluate, learn and adjust
• At the end of every sprint and in larger timeframes
8
Q
What are the principles of Scrum?
A
- Split a project into brief manageable ‘sprints’ (2-4 weeks) –> facilitated by scrum master
- Utilize teams better
• They only focus on the sprint, after that they can go back to their department and do some studying for instance - Development and test
- Handle changes in requirements
- Product backlog: Large pool of things to be done, ordered by priority by the user
- Sprint backlog: What you want to do in this sprint. Teams normally know how much work to take into the sprint
- Iteration: Make the previous product better
- Testing: New thing integrated and is tested
- Daily stand-up: Should be very short (10-20 min)
- Potentially Shippable Product Increment: Improvement on the previous product. It is shippable because it is tested after every sprint
9
Q
What are the principles of Extreme Programming (XP)?
A
Coding - Testing - Listening (what the customer really wants, but also observing the customer) - Designing
- Embrace Change: describe what the program should do in terms of user stories
- Pair programming: work together in pairs (better quality); no owner of code (If you write code, everyone else is able to finish it. Very clear variable names, comments etc. to make sure everyone understands it
- Test-First programming: first write test (define how the code should be working), then develop code, and then run test
- Continuous integration: code changes are tested when they are added to a larger code base
10
Q
Work Breakdown Structure (WBS)
A
- Goal tree: when all leaves fulfilled, goal fulfilled
- For each goal, which activities need to be done.
- For each goal, when is it considered ‘ready’.
11
Q
What are the principles of PRINCE2?
A
Generic project management methodolgy with 8 process groups and 45 separate subprocesses
- Starting up a project
- Planning
- Initiating a project
- Directing a project
- Controlling a stage
- Managing product delivery
- Managing stage boundaries
- Closing a project
12
Q
What are the 6 crucial practices leaders should adopt if they want to capitalize on agile’s potential? (Rigby, Sutherland & Takeuchi, 2016)
A
- Learn how agile really works
- Understand where agile does or does not work
- Start small and let the word spread
- Allow “master” teams to customize their practices
- Practice agile at the top
- Destroy the barriers to agile behaviors
13
Q
What is the main message of the article: No silver bullet? (Brooks, 1987)
A
- “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”
- “But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order- of-magnitude improvement in productivity, in reliability, in simplicity.
14
Q
Initial sketch
A
Communication between the developer, commissioner/sponsor and end user
A mock-up that is used as an early agreement
15
Q
Use Case Diagram (UML)
A
Can help in the early stages to systematically record the (hidden) system requirements by writing down “use cases”: ways of using the system. It declares what and not how
- Primary actors
- Secondary actors
- Goals
- Context
- Precondition
- Success
- Failure
Purpose:
- Generate new requirements as the design takes shape
- Communicate with stakeholders
- Generate test cases
16
Q
Functional requirements
A
Actions the system should perform (if I press this button, this should happen). Can be assigned to individual components of the system
17
Q
Non-functional requirements
A
General properties the system should have (performance, security, reliability, usability, scalability, integrity etc.). Applies to the system as a whole
18
Q
Design as a dialogue
A
- Principal (customer) and agent (developer)
- Developer knows the domain, but doesn’t know the customer needs
- Customer has needs, but doesn’t know what system they want
- Interpretation, negotiation, rapid prototyping, iterative, trying out real versions of the product, solving problems together
19
Q
Requirements and design/configuration collaboration
A
Requirements are satisfied by components; components trigger new requirements; repeat until stable and feasible Requirement: Fast computer Component: Intel Core i7 Requirement: Cooling Component: Fan
Configuration: Problem closed, principles known, parts standard
Design: Problem open, principles unknown, parts to be developed
20
Q
What are the 4 inherent properties/nature of software problems? (Brooks, 1987)
A
Complexity:
- Function of number of components/types of components/attributes/relations
- Function points are used for predicting effort, duration and errors
- Essence (inherent to the nature) and accidents (we have created –> bureaucracy etc.)
- Difficulty of communicating, enumerating and unreliability
Conformance:
- No universal standards/laws of nature
- Software has to conform to external expectations and norms, which differ between contexts
Changeability:
- Software can and must be changed, even after production (updates)
- New uses of existing software, software survives beyond the machine for which it is written
- There is always change, software should follow (VAT changes)
Invisibility:
- Software is abstract, not embedded in time and space
- Not one natural representation of structure, but several (data, process)
21
Q
How can the nature of software problems be addressed? (Brooks, 1987)
A
- Remove accidental difficulties (make it easier for the developer)
- Address conceptual essence: buy vs build, requirements refinement, great designers
- Agile: remove accidenetal difficulties and address inherent complexity
22
Q
How to address complexity? (Boehm, 1988)
A
Little by little
Iterative development
- Early results
- Feedback
- Learn and improve
Loosely coupled architecture
- Less dependencies
- Local decision making in clusters
Centralize
- From O(n2) to O(n) connections (less dependencies)
Standardization
- System of systems
- Interoperability
Re-use
- Buy vs build
- Libraries; task models; domain models
- Organizational learning
23
Q
Brooks law
A
Adding manpower to a late software project makes it later
- New members need to learn, as software projects are complex. This takes existing resources away from development
- Draws communication overhead (number and variety of communication channels)
24
Q
Requirements engineering
A
Has the task to align the needs and environment with the requirements specification
discipline to “capture, share, represent, analyze, negotiate, and prioritize requirements as a basis for design decisions and interventions” (Jarke et al, 2011)
Verification: Test if the system was built right (according to requirements) –> code walkthrough
Validation: Test if the right system was built (according to stakeholder needs and environment) –> experiments, inverviews, acceptance tests
25
What are the 4 requirement principles that will underlie successful design and RE in the "brave" new world of requirements? (Jarke et al, 2011)
Intertwine requirements and contexts
- Organizational and business context
Evolve design and ecologies
- See design (processes) as evolving elements in an ecology
Manage through architectures
- Consider them as enablers and constraints in the continuous creation and shaping of design ecologies
Recognize complexity
- It demands new ways to approach design problems and manage requirements
These exhibit a high degree of causality and work in a causal loop
26
Business case
- Must provide management with the information needed to make an informed decision whether a project should receive funding, or go to the next phase
- Is complete (all benefits, costs and risks), systematic and objective (judge/evaluate all projects the same way)
- Made by cross-functional team (all departments) for credibility, alignment and access to real costs
27
Measurable Organizational Value (MOV)
Scope, Schedule, Budget, Quality
1. Identify area of impact (which departments is mostly affected by this project?)
2. Identify organizational value (better, faster, cheaper, more)
3. Develop appropriate metric
(money, %change, counts)
4. Set a time frame to achieve MOV
5. Verify and get agreement from stakeholders (on basis of the MOV)
6. Summarize MOV clearly and concisely
Organization Vision and Mission, Organization Strategy and Project's measurable value should be connected to each other
28
Payback (period)
Investment/cash flow = amount of month or years.
Cash flow = Benefits - Costs in a period
100.000 / 20.000 = 5 years
Ignores the time value of money and is used as yardstick
29
Break even point
Investment/net profit margin = number/price amount
Fixed costs: 100.000
Variable costs: 25
Sales price: 30
100.000 / (30-25) = 20.000 units to break even
30
Return On Investment (ROI)
((expected benefits - expected costs)/expected costs) x 100%
((115.000 - 100.000) / 100.000) x 100% = 15%
31
Net Present Value (NPV)
Acounts for the time value of money by a discount.
NPV > 0: return from a project exceeds the cost of capital
- initial investment + (for n, t = 1) ((benefits(t) - costs(t))/(1+r)^t)
```
r = discount rate
t = time period
```
32
Total cost of ownership
- Direct or up-front costs: purchase price of hardware, software, and telecommunications equipment, all development or installation costs, outside consultant fees, etc.
- Ongoing costs: Support, salaries, training, upgrades, supplies, maintenance, etc.
- Indirect costs: Initial loss of productivity, time lost by users when system is down, cost of auditing, quality assurance, and postimplementation reviews.
33
Total benefits of ownership
- Increasing high-value work: value-added to the customer (see Lean)
- Improving accuracy: reducing errors, duplication, rework
- Improving efficiency: reducing effort, duration or number of steps
- Improving decision making: providing timely and accurate information.
- Improving customer service: new products or services, faster or more reliable service, …
34
Intangible benefits
- More long-term and fundamental elements of an organization. You can’t see the direct benefit in dollars profit from it
- Some benefits are hard to estimate, because they are hard to quantify (measure).
- Some benefits are hard to estimate, because they only affect the business indirectly.
Examples: Improved data quality, better decisions, improved customer satisfaction, easier to innovate.
Intangible, but not unmeasurable
You can relate intangibles to tangibles, to make them measurable
Tangible = directly affects the firm's profitability
35
Decision theory and scenario planning
Used to compare alternatives (business cases) based on conditions and weights
36
Feasability (4 types)
- Economic: business case, budget
- Technical: availability of data, interoperability, maintainability, complexity
- Organizational/social: support, expertise, adoption among end users, HR
- Other: legal, logistics, planning, ...
37
Risk
Likelihood (0-1) x impact (monetary value/cost of the risk)
- Identification: what are the risks? (people risk, overrun)
- Assessment: how large is the risk? (often H, M, L or expected monetary value (likelihood x losses x duration)
- Response: avoid (stopping project), accept (prepare by having a financial buffer), transfer (insurance), mitigate (lower likelihood and/or impact, having a plan B), escalate
38
5 sources of risks in projects
- Market risk: Is the product useful, will it be accepted?
- Financial risk: Will the project meet NPV, ROI and payback estimates?
- Technology risk: Is it technically feasible, will it function properly?
- People risk: Appropriate skills to complete the project, management support?
- Structure/process risk: What degree of change will occur, with many systems does it need to interact?
39
Considering risk, how do you determine the best project?
Add up the positive and negative Estimated Monetary Value (EMV) (probability x money)
The project with the highest EMV is the best
40
Hidden costs and why do they remain hidden?
- Known costs, but budgeted too low (bad estimate)
- Unknown costs, not budgeted
Remain hidden because:
- Incentive to boost benefits and hide costs (to gain advantage over other projects)
- Indirect costs are really unknown (complexity, involvement of compliance personnel)
41
Portfolio management
- Portfolio of projects with varying levels of risk, technology, size and purpose in order to meet organizational objectives
- Prioritize: top projects for which there is funding get selected
42
Scope grope, creep and leap
- Grope: inability to define the project's scope
- Creep: tendency to increase features
- Leap: fundamental change in project scope (loss of previous investments)
43
6 types of Development Cost Estimation
- Guestimating: guessing based on estimates (earlier/similar projects
o estimates often unreliable (underestimate, buffers)
- Delphi technique: multiple experts arrive at consensus (G DSS)
- Time boxing: focus on only the most important features (Scrum)
- Top-down estimating: how long it should take, should cost (budgeting)….
- Bottom-up estimating: based on experience of PM and teams
- Planning Poker: reliable estimates; support; collaboration
o Players: people who actually do the work (local expertise)
o Deck of cards (cost estimates): 0, ½, 1, 2, 3, 5, 8, 13 … (fibonacci, subjective judgement)
o Feature list: what needs to be delivered (user stories) --> people talking about requirements, how complex/large is it to build?
o After all questions are answered, each player makes ‘bid’ (story points)
o Motivate scores; discuss; --> new estimate
44
Software metrics
- Lines of code (LOC) --> time --> developer salary cost.
Doesn't show how complex the lines are
- Function points: amount of functionality (based on requirements)
45
Difference between complex and complicated
Complicated implies being difficult to understand but with time and effort, ultimately knowable. Complex, on the other hand, describes the interactions between a number of entities (mathematical)
46
Function points
- Ordinal measure (can be put on a scale, similar to km or hours) of size and complexity of a software product
- Compositionality: break systems into smaller components, so they can be better understood and analyzed. [but: architecture, security ]. You can calculate the total as the sum of the function points of the smaller components
- Provide an objective measure for evaluation, planning, management and control of software production
There are five standard functions:
- Data Functions:
o Internal logical files (ILF)
o External interface files (EIF)
- Transactional Functions:
o External Inputs (EI)
o External Outputs (EO)
o External Inquiries (EQ)
Estimate complexity:
- low, average, high
47
COCOMO
- Interactive cost estimation software packages (DSS) that models the cost, effort and schedule for a new software development activity
- Can be used on new systems and on upgrades
- Works less for Agile and more modern projects
- Empirical model (no underlying cognitive theory on why software is difficult)
48
COCOMO-II
Basic model: rough estimates of project cost, performance and schedule
```
Intermediate model (used most often)
- Uses Effort Adjustment Factor (EAF) based on cost drivers (lines of code/FP are multiplied by this EAF)
```
Detailed model
- Uses different effort multipliers for each phase of project
The more complex the model, and the more factors that influence a software project are accounted for, and the more accurate the cost estimate will be. (You don’t want to spend too much time on a project that you are likely not going to do anyway)
49
Internal Rate of Return (IRR)
Aims to find the discount rate that would equate the present value of estimated cash outflows with the present value of inflows. If this rate is greater than the required rate of return, the project may be accepted
50
Profitability Index Method
Extension of the two DCF techniques
It provides comparative profitability among different investments by dividing the present value of future cash flows by a project's initial investment.
A limitation of these techniques is that they are based on estimates of benefits and cash flows. And, it only focuses on the financial criteria, but there other criteria that should be, and in practice are, considered by the managerial decision maker
51
Accounting Rate of Return (ARR)
Average annual income / initial capital investment
Ignores time value of money and used as yardstick
52
Scrum master
Makes sure the team works according to the Scrum method, clears difficulties of the process. Make sure the team can focus on their job
53
Facilitator
Buffer (outside world should not interfere the team), should serve the team as the team is most important
54
Product owner
Could be from the end-user business. Ensures crucial features are included, prioritizes
55
Development team
Autonomous, deliver quality specialists, generalists (3-9 people)
56
How is communicated in Scrum?
- Daily scrum: short stand-up meeting; identify problems, assign tasks
- Face-to-face: not much written documentation within the team
- Make progress visible (Kanban Board)
57
What are the rituals of Scrum?
- Sprint: time-boxed effort (2-4 weeks); facilitated by scrum master
o Planning: (max 4 hours for a 2-week sprint) --> Product owner and Scrum master
o communicate goals, select backlog items, prepare (decompose task)
o Daily Scrum (max 15 min)
what did I do? what will I do? any impediments?
o Review and retrospective (2 hours)
review work that was completed and not completed, and present to stakeholders (demo)
retrospective: reflect on sprint, and agree on improvements
- Extensions and adjustments …
o Backlog refinement: reviewing priorities of backlog items
o Scrum of Scrums: coordinate multiple teams on the same product
These rituals are very strict
58
What are the artefacts of Scrum?
Product backlog: Items to work on; ordered list of requirements
- Prioritized by product owner
- Items are written as story; what will be delivered
- Record expected business value (all features together); risk and dependencies
Sprint backlog: Work for development team in next sprint
- Select what the team can handle (based on past performance)
- Team maintains it
- Often linked to task board (to do, in progress, testing done)
Product increment: Sum of completed product backlog items in a sprint
- Integrated with previous result (= potentially shippable product)
- Definition of done (e.g. must be tested), adhere to security, architecture, quality standards
- Show to end user/customer
59
What are the management tools of Scrum?
- Planning poker
o Estimate amount of work (using expertise in the team)
- Sprint burn-down chart:
o Shows remaining work in sprint backlog
o Updated in daily scrum
- Release burn-up chart:
o Shows progress towards scheduled release
- Discussion:
o Key performance indicators for a Scrum team?
60
Why does Scrum work?
- Handle change, uncertainty: Add user stories; prioritize; review and retrospective
- Handle complexity: Decomposition in sprints (Scrum only works then); good teams
- Time gains: Only do important stuff; communication; focus on one project
61
Scaled Agile
How to coordinate multiple teams and align them with business objectives?
- SAFE
o Formal roles and responsibilities; epics (ways of organizing business ideas before they become specific enough to become user stories); budgeting
o Agile release train (pipeline with very strict loses of going from one stage to another)
- LeSS (Large Scale Scrum) Bas Vodde, Craig Larman
o Lightweight framework
o Experimentation so teams and organizations can adapt (what works for that particular environment) --> Later these become fixed
- Spotify model, Henrik Kniberg
o Hybrid; based on LeSS and corporate culture (engineering culture with focus on excellence and technical abilities and quality is key to succeed)
62
Agile Project Management
- Short cycles of iterative and incremental delivery
- Shift from up-front planning to decision making during the project
Four principles of agile project management
o Minimum critical specification: no more should be specified than is absolutely essential to overall success (decided by team)
o Autonomous teams: autonomous teams are responsible for managing and monitoring their processes and executing tasks (rest of the organization accepts these decisions)
o Redundancy: team members are skilled in more than one function
o Feedback and learning: integral to project execution and interaction with the environment (to deal with ‘wicked problems’ --> they don’t have a fixed solution)
Shared decision making: Teams are involved in strategic decisions and management/product owners are sometimes involved in the operational decisions
63
The equal principles of Agile and Lean
Value: better alignment with customer (no wastage)
Flow: fast sprints, continuous delivery, immediate feedback
64
Lean
Focuses on removal of wastage (anything not necessary to produce the product or service, it adds no value)
1. Identify features that create value
2. Identify the sequence of activities (value stream)
3. Make the activities flow
4. Let the customer pull the product/service through the process (demand-oriented)
5. Perfect the process
Or DMAIC for Six Sigma
65
Business Process Re-engineering
1. Organize around outcomes, not tasks
2. Have those who use the output of the process perform the process.
3. Subsume information-processing into the real work that produces the information
4. Treat geographically dispersed resources as though centralized
5. Link parallel activities instead of later integrating their results.
6. Put the decision point where the work is performed, and build control into the process.
7. Capture information once and at the source.
66
DevOps
Set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production (release management), while ensuring high quality.
Put people from operations in the development team
- Governance: well defined roles and responsibilities; phases in the process
- Technical infrastructure: delivery pipeline (series of programming environments with clear status changes to move in the next change when it is ready); ensure right software ends up in production
67
Continuous Development (Fitzgerald and Stol, 2015)
- Combine several trends that embrace continuous change
o Agile enterprise: ability to respond to internal and external change
o DevOps: align development of software and taking in production
o Beyond budgeting: adjust budgets to changing business needs (vision/objectives)
o Lean and startups: continuous improvement, build-measure-learn, fail fast
- … with Lean thinking (Ohno 1988; Womack and Jones 2003);
o value and waste: reduce non-value added activities
o flow and batch size: focus on visual flow (Kanban)
o human automation: built-in quality (jidoka); fool proof (poka-yoka)
o Kaizen: continuous improvement
- into Continuous (something)
68
Epics
Bits of innovation/business ideas (pretty abstract, could turn out to be a project if approved), not yet user stories
69
Project manager
Assist product owner in working on requirements and handle other matters that those directly related to software development, such as internal and external reporting
70
Stakeholder
Any person, group or organization that can place a claim on the organization’s attention, resources, or output, or is affected by that output
Internal: end users, system administration, business, sales, internal audit, risk management etc.
External: end users, citizens, consumers, producers, sponsors, initiators, regulators, general public
71
Leeway
Leave space to disagree and for politics in the details (flexibility in the design)
72
Winning coalition
Powerful group of people to get the decisions through
73
What is the timeline (5 stages) for the idea of improving social problems?
- Incubation: Idea needs to grow/develop from an initial to a good idea
- Coalition formation: Other people will start to support this idea
- Trial and error: Learn and improve
- Success: First major success
- Consolidation: Success is scaled up
74
Power versus Interest Grid
Interest: High or low
Power: High or low
Crowd: Low interest, Low power (Monitor)
Subjects: High interest, Low power (Keep informed)
Context setters: Low interest, High power (Keep satisfied)
Players: High interest, High power (Manage closely)
It is initiated by the project leader or party
75
Problem-Frame Stakeholder map
Q. How to move a powerful stakeholder from ‘opposed’ to ‘supportive’?
A. By altering their interests: settling an issue in their advantage.
Example: Forest on Maasvlakte to get environmentalists to agree.
NB. May lead to ‘sub-ideal’ solution (from engineering point of view) initially, but must be accepted as outcome of ‘the process’ (otherwise it wouldn’t be built at all)
Opposition/support: High or Low
Power: High or Low
Weak opponents: Opposition, Low
Weak supporters: Support, Low
Strong opponents: Opposition, High
Strong supporters: Support, High
76
What is the trade-off in risk management?
Of some things in life we never have enough: safety, security, …, meeting objectives, but they come at a cost: investment, opportunity costs, reduction of usability, reduction of flexibility, etc.
77
Risk management
Likelihood of an event occuring, multiplied by the impact of that event on the organization's objectives
Steps:
- Risk assessment: Likelihood and impact
- Risk mitigation: Avoid, reduce, transfer, accept
- Evaluation and assessment
78
Control measures
Measures implemented to prevent, or else to detect and correct a risk, an event that might result in not meeting objectives.
- Preventative measures: make risk (nearly) impossible to occur
o E.g. DTAP prevents untested software taken into production
- Detective measures: make sure no risks go unnoticed
o E.g. all projects have a clear beginning, and a clear end. Duration is known and can be evaluated (learning cycle)
o E.g. burn down chart: how does budget compare to results?
- Corrective measures: when detected, react appropriately
o E.g. change a badly functioning team
o But: adding people to a project that is late, will make it later!
79
Open Source Software (OSS)
Type of software in which source code is open for study, modification and redistribution.
Free as in freedom: If I sell the code to someone, I give the right to them to modify and redistribute it to someone else
80
Open Source Software Business Models
- Selling services around the open source software (E.g. RedHat)
o Typical services - training, technical support, integration, or consulting,
- Open core model (e.g. Oracle's MySQL database)
o Selling optional proprietary extensions to the software e.g. security features
o Dual licensing (Personal use access, often free; enterprise access costs money)
o Freemium
Create a basic functionality for free and make more advanced features for different segments that needs to be bought (optimization, security etc.)
- Software as a service (Cloud services; e.g. mongoDB)
o Charges users subscription to access various tiers of functionality (e.g. data storage and computing power)
o Is it a loophole?
- Voluntary donations
o Crowd funding, donations, and bounties
o In 2019, GitHub introduces sponsors – Patreon type support for developers
81
Open Source Software types of licensing
Restrictive Licenses
- Restricts a company from hijacking the software and commercializing it, you can’t sell the slightly changed software under your name
- Free Software Foundation (FSF)
- Viral/copyleft policy – any software that uses a restrictive licensed software should adopt the same license
- Example: Linux Kernel, GNU Compiler Collection
- Socialist ideology (if I share it, other people can do whatever they want with it, if they follow the restrictions of me) Don’t reuse it for commercial purposes
Permissive Licenses
- Allows you to do whatever you want with the OSS, you can commercialize if you want
- Open Source Initiative (OSI)
- Permits the user/developer to change the license
- Example: Apache webserver, Python
- Liberal ideology
82
Open Source Software types of version control
Versioning is the practice of tracking and controlling changes to source code
- Version control
o Big challenge for collaboration – how to manage the different versions that people may write code on
- Centralized version control systems (CVCS) e.g. Subversion
o Central server –central repository (project folder with all code and versions) that contains the main source code
o Distributed client – check-in code changes once done
o Problems?
Multiple people working on the code, different versions. The management of this happens in the central repository, it different and time-consuming. It is less of a problem of you know how is working on it and what he is working on (within an organization). In open source this is not the case, they develop features independently and can even be working offline
To overcome the problems stated above
- Decentralized version control systems (DVCS) e.g. Git
o Entire project including all its history and changes are copied in the local system
o Less dependent on server-Local copies serve as backup. Downtime can be management easily
o Conflicts lower - Every developer work on their own piece of code and test it before merging
If all conflicts are resolved (everything is matched), the local code can be merged into the main code
A conflict can also be to merge two very alike features into one consent
83
Fork and merge
Making a copy of the project and integrating the code changes with the project
o The idea of open source is that everybody can contribute to the project
Even with limited programming skills, you have the rights to change it. But you need to ensure quality
o But how do you manage contributions coming from anywhere?
o Fork: creating a full (local) copy of a project for re-use and development
Branch is similar to a fork but does not require full project history to be copied
o Merge: integrating a fork or a branch to the main project code (master)
To merge a fork or branch you need to make a request to ‘pull’ your changes to the master
o Review and control contributions
Peer review by core contributors before merging the code changes with the master branch. Mainly the Project Maintainer (developer that is good enough employees of Facebook themself). If it has some value, it will be added. If there are requirements needed, he will give feedback to the contributor. Also, the more you contribute to the code, the more rights you will get from the maintainer and you can even become a maintainer yourself.
84
Open Source Software types of workflow
Workflows are the paths that describe how something goes from being undone to done, or raw to processed
Basic workflow
- Sequential and incremental
- Each developer forks/branches the project --> works locally on the code --> sends a request to merge its code to the master
- Great for simple and modular projects where there are no dependencies
Feature-Branch
- What do you do when you have multiple developers working on features that depend on each other? --> Create a feature branch and merge it after development
- Manage releases effectively: release early, release often
- Branches are independent “tracks” of developing a project, where the new feature is developed and tested
- Once the feature is ready, the branch can be merged to the main branch so it can be released to LIVE
85
Open Source Software - Contributor and Collaborator
Write Access Contributors (Collaborator)
- Core contributors
- Community given status
- Meritocracy for access provision
- Identity features
- Can make changes to the source code, mainly the project owner. He can offer this right to any contributor that is worthy of that right
- They monitor the quality, peer-review etc.
No Write Access Contributors
- Peripheral contributors
- Any individual can submit code
- Less active
- A large workforce; perform routine tasks and ad-hoc solutions
- Identify and notify issues, but it first has to be accepted by the product owner/maintainer
86
Do-ocretic (meritocratic) assignment of responsibilities in OSS
A person who has spent a lot of effort will get some additional rights by the maintainer (write access to directly make changes, it doesn't require review from me anymore)
87
Responsibilities of mature projects in OSS
o Read: Recommended for non-code contributors who want to view or discuss your project
o Triage: Recommended for contributors who need to proactively manage issues and pull requests without write access
Filter only the important features for peer-review.
o Write: Recommended for contributors who actively push to your project
Implies a lot of trust from the product owner
o Maintain: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions
o Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository
88
What motivates programmers to participate in OSS?
- Net benefit from engaging
- Time is a cost (not able to work for commercial firm or not focusing on his primary mission)
- Benefits (finding specific solutions for their employer, compares how enjoyable the mission of the employer vs the OS alternative is)
- Delayed reward (career concern, ego gratification) = signaling incentive
- Signaling incentive is stronger when (performance more visible to audience, higher impact of effort on performance, performance more informative about talent)
89
Incentives: Open Source Software vs Closed Source Programming
- The proprietary nature in commercial firms can generate income and offer salaries
- OSS may lower the cost of the programmer (alumni effect: used in schools for learning --> already familiar to programmers, customization and bug-fixing benefits)
- Signaling incentives are stronger in OSS (better performance measurement, full initiative, greater fluidity)
- Sophisticated users derive direct benefits when they customize or fix a bug in OSS
- OS processes give opportunity to signal talents to peers, employers and venture capital
90
Why don't corporations duplicate the OS incentives?
- They will never be able to fully duplicate the visibility of performance reached in the open source world
- Commercial companies do not like their key employees to become highly visible, lest they be hired away by competitors. But to a large extent, they also realize that this visibility enables them to attract talented individuals and provides a powerful incentive to existing employees
- In some instances, the groups seek to prevent being broken up by not documenting a large number of program features
91
Commercial OSS strategies
- Provide complementary services and products (reactive)
- Encourage or subsidize the OS movement to make more money for support
- Release existing proprietary code (proactive strategy). The company expects to boost its profit on a complementary segment or does it if the increase in profit in the proprietary complementary segment offsets any profit that would have been made in the primary segment (particularly when a company is too small to compete)
- Leadership by commercial entity may not internalize enough of the objectives of the open source community
- Can serve as a intermediary: contact developers, prepare contracts, settling disputes etc.
92
Which method for which situation? (KPMG)
X-axis: Close to or far from uncertainty
Y-axis: Close to or far from agreement
Simple (straightforward, everything is known): Waterfall
Technically complicated (a bit uncertain, more is known than unknown): Agile
Socially compliacted (a bit far from agreement, more is known than unknown): Agile
Complex (more is unknown than known): Agile
Chaos (unpredictability, very little is known): No best method
93
Wicked problems (KPMG)
- No definition of the problem
- Not clear what counts as a solution
- Solution is unique
- Related to other problems
94
Mess (KPMG)
“Every problem interacts with other problems and is therefore part of a set of interrelated problems, a system of problems… I choose to call such a system a mess.”
The role of consultants is to clear up the mess
95
Traditional Project Management (KPMG)
A predetermined sequence (hierarchical), based on stage gates, you get a stamp on it and it can continue into the next phase
Plan-driven: Cost and schedule are estimates, requirements are constraints
96
Agile (KPMG)
Work in cycles (iterative). People dynamically working together, checking if the project is on the right track, ask the client if we are delivering value etc. (interactive).
People should be able to do more than one role. Someone with a specialization could be involved in multiple teams at a time. And the team is a diversity of different people and skills.
Value/vision-driven: Features are estimates, cost and schedule are constraints --> It will take this much time and this is the budget, from there you prioritize the features
97
What are the 3 levels of (IT) change in Quality Assurance? (KPMG)
- Portfolio Management: Strategic level. In control of complete change agenda of the organization (define strategy and vision, allowing project to be set up and deliver results that are part of the strategic vision of the organization)
- Program Execution: Responsible to meet the objectives and do the project delivery
- Project Delivery: Delivering results
98
Doing the right things and doing the things right (KPMG)
- Doing the right things: To deliver things that are in line with the vision of the organization
- Doing the things right: In a controlled environment to actually achieve and meet the strategic goals and benefits
99
The 7 key success factors in projects (KPMG)
Program Plan & Control
- Programme Governance: Effective leadership, clear responsibilities and committed stakeholders
- Programme Management: Well-managed scope, costs, risks, issues and progress
- Change Management: Embraced vision, change barriers removed
- Performance Management: Realistic business case, benefits tracked
Program execution
- Process: Processes aligned and adopted
- Technologies: Technology enables and supports change objectives
- People: Organization ready for change
Agile is in all of them
100
Auditable (KPMG)
You can document and formalize that you are in control of the project. Is important because you want to know in the future, when something from the project is not working anymore, why did I do this in the first place? What exactly did I change? Who made the decision?
These are questions you want to know to remain in control of the organization
101
Agile ceremonies (KPMG)
Time: Set variable in agile projects. Constraint for every sprint. Monitoring and control of this variable is performed through:
- Velocity (completed stories per sprint)
- Backlog/burndown chart
- Sprint backlog
- Product backlog
- Rework
- Testing
- Acceptance of product by user
Cost: Set variable in agile projects. Constraint for every sprint (availability of resources). Monitoring and control of this variable is performed through:
- Change management process
- Prioritization of requirements
- Customer involvement
- KPI's
- Benefits realization
Features/Quality: Dependent variable in agile projects. Driven by cost and time estimates. Quality control is of utmost importance. Monitoring and control of this variable is performed through:
- Definition of Done (DoD)
- Testing approach
- Number of defects
- Product owner sign-off
- Link between epics, stories, tasks, testing and DoD
- Auditable and compliant
102
Challenges within an Agile environment (typically when Agile maturity is low) (KPMG)
- Team autonomy: Lack of control, reliance on members' skills and knowledge, lack of strategic direction
- Speed: Decrease in quality, lack of testing efforts, minimal communication
- Flexibility: Changing requirements, dynamic project management
- Short-term focus: Tactical decision-making, business IT misalignment, no actual sustainable business value
- Minimal documentation: System maintenance issues, lack of monitoring opportunities, auditability of the project
- Small teams: Lack of independence, increase in risk-appetite, underestimating complexity
103
Three lines of defense model (KPMG)
1st line: Management controls, internal control measures --> Senior management
2nd line: Financial control, security, risk management, quality, inspection, compliance --> Senior management
3rd line: Internal audit --> Governing body/board/Audit committe
Agile transformation starts at the first line of defense (operations), the other lines also have to transform which makes it difficult (to stay in control of Agile). Therefore, most of the times Agile is only implemented in the operations
104
How is autonomy done in Rabobank?
Autonomy within the team, but therefore the boundaries of the teams need to be fixed. This is maintained by the Definition of Done (DoD)
Autonomy
- Squads need to evolve constantly to keep up with competition, technology and new customer demands
- Autonomy enables them to do this fast (without being constraint by the organization)
Alignment:
- Squads benefit from being part of a greater organization through advantages of scale & skill (efficiency)
- This demands alignment of squads through common purpose, unambiguous goals, standard rituals, best practices (provided by chapters), shared resources (e.g. client services) etc.
There is Aligned Autonomy: Squads decide how they can contribute best to the overall strategic objectives (what/why)
Still teams having their own autonomy to do things, but aligned so we have the same goals and roadmaps to work towards
105
Squads (Rabobank)
- Multi-disciplinary teams dedicated towards a common purpose (every disicipline that is needed is present) (around 8 FTE)
- Own a service and are responsible for run, change & win
For their specific service, they need to:
- Understand users, competitors, regulations & technology
- Develop long-term vision and translation to roadmaps
- Execute business case (cost vs income)
- Keep the lights on (operations)
- Develop a future proof tech stack (incl. decomm. legacy IT)
- Product owner determines priorities (backlog) and ensures transparency and stakeholder alignment
- Squads are grouped in area's & tribes
106
Chapter (Rabobank)
In the squads, the disciplines are aligned in a chapter. All developers are scattered around different squads, but together they are organized in a chapter (hierarchy), a group of people with the same expertise-area/similar skill set which has one boss that is responsible for resources, hiring, training, standards, reviews etc. So, HR is not in a tribe, squad or chapter
For example product chapter, scrum master chapter, development chapter, QA chapter, UX chapter
107
Tribe (Rabobank)
Based on a type of product (Wonen, Payments, Ondernemen, Pensions, Digital Customer Processes etc.). Collection of squads/teams that work on an area/service (200-400 FTE)
Each tribe has the client service (helping customers) and chapters (hierarchy in the organization)
108
How is the organization structured? (Rabobank)
This is a stable standing organization, no longer work in projects. We have a team that is assigned to a certain piece of new work/priorities
No steering committees, no project governance with the conviction that is change is constant/normal and we need to make sure everything is working together (you have a stable organization where everyone knows each other already, you don’t waste time to set up resources for a project)
Board sets priorities --> Know your customer, decommission of legacy IT, improve sales
They are divided on the tribes (business person is lead, IT domain lead, architect) --> Triangle that is together responsible to do it, the squads are looking how they do it
Culture are the unwritten rules, norms, quality etc.
Gardening metaphor: Grow a culture, water the plants, provide manure, make it easier for people to follow the new culture, conditions to facilitate the culture, let it grow organically with guidance. For example, salary based on performance or provide training (management support the value of training)
109
What makes you go faster? With slack (75% utilization) or no slack (100% utilization)? (Rabobank)
More slack makes you go faster. Create a backlog of around 75% of capacity makes you go faster (leaves room for change and discussion). This mindset is hard to break in the company, it is much better to not use the full capacity
110
What is faster? Serializing or parallelizing? (Rabobank)
Serializing is faster than parallelizing. This is the same with product backlogs. Make sure there is one piece flow, one priority at a time
111
Leadership team (Agile)
Sets priorities, establishes innovation teams, assigns leaders to teams, removes impediments
112
Process facilitator (Agile)
Trains the team on Agile techniques, facilitates meetings, coaches members, makes work visible, protects the team members
113
Crusaders, tailors and dabblers
o Crusaders: exclusively adopt agile in a pure form
All of the elements are used
o Tailors: integrate agile and traditional to fit specific circumstances
You cannot do standup meetings if you have a team that is spread around the world
o Dabblers: ceremonial agile activities along traditional approach
Only the outside looks Agile, but they didn’t really change the traditional approach. They actually don’t know they didn’t change that much (they won’t have much benefits)
114
Deliverables, activities/tasks and dependencies (planning)
- Deliverables: documents, milestones, definition of done
- Activities/tasks: precedence (A needed before B) or (A parallel to B)
- Dependencies: outcome A needed for success of B (approval by manager, budget constraints)
115
Critical path
The longest path that must be followed
116
Why is technology development specifically hard?
The client doesn't know what they can want, need a dialogue
117
Shared decision making in Agile
Teams are involved in strategic decisions and management/product owners are sometimes involved in the operational decisions
118
What is important for collaboration in networks?
- In a network, parties have different interests and are interdependent (they need each other). This hampers collective decision making.
- If a policy analysis is made to support the decision making, the findings from this analysis are likely to lack authority.
- For a policy analysis to be authoritative and to contribute to collective decision making, a process of interaction between the analyst and the parties concerned should be organized.
o Doesn’t really matter what comes out of the process, it matters that you follow the steps and make sure that every stakeholder has a say in the process (so they can’t come back on their decision
- This is called process management. This article presents a number of guidelines for such a process. They are based on two case studies into the use of policy analysis in networks.
- Conclusion: “This presents a picture typical of process management: offer stakeholders room in the process, but make sure that the process is of such a high quality that stakeholders feel less and less need to use this room as the process proceeds.” (p 242)
119
What are the issues for distribution of revenues from a project?
- Issue 1. revenues not for those who need to make investments
o redistribute revenues and costs over parties (subsidy) that took risks in the earliest stages (prefinancing)
- Issue 2. revenues not when investments are needed
o need to pre-finance investments; revenues come later
- Issue 3. there are good reasons not to change (barriers)
o need a reason to overcome barriers
A sustainable business model ensures (1) fair distribution of revenues over parties, (2) fair redistribution of revenues over time, (3) a good reason to resolve barriers to change
120
People determined theory, system theory and interaction theory in stakeholder management
- People determined theory: divisional accountants are different: “troublemakers’
- System theory: all kinds of technical problems (e.g. data entry cumbersome)
- According to the interaction theory, resistance can be attributed to an interaction between the design features of the system and features of its organization and social context of use.
121
Stakeholder issue diagram
- Issues can be 'traded'
- Issues can be linked
Group E would be the pivoting role between several stakeholder groups. Essential to have on board in the coalition
Enlarge the problem in several issues to get more stakeholders on board
122
The scrum method in Rabobank
Start with a roadmap (where you want to go, goals, vision etc.), refinement in to tribe backlog (activities that are needed), planned into a sprint backlog in where a squad works in it in 2-4 weeks with daily standups, increments etc., then review how the sprint was done, what could be better and then make a retrospective to refine the roadmap
123
The 19 principles of The Cathedral and the Bazaar (Eric S. Raymond, 1997)
1. Every good work of software starts by scratching a developer's personal itch
2. Good programmers know what to write, great ones know what to rewrite (and reuse)
3. "Plan to throw one away; you will, anyhow"
4. If you have the right attitude, interesting problems will find you
5. When you lose interest in a program, your last duty is to hand it off to a competent successor
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging
7. Release early, release often, and listen to your customers
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone
9. Smart data structures and dumb code works a lot better than the other way around
10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong
13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible – and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend
17. A security system is only as secure as its secret. Beware of pseudo-secrets
18. To solve an interesting problem, start by finding a problem that is interesting to you
19. Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one
