###### tags: `BSUP`
# Helle BSUP exam notes

# Ekstra material + good figures
## Project Management Life Cycle vs. Software Development Life Cycle

## What is a project?
A project is where you is in the current state -> want to be in the desired state

# Articles to master for the exam
## Ken Schwaber and Jeff Sutherland. "**The scrum guide. The definitive guide to scrum: The rules of the game**". Scrum. org (2020).

Scrum is
- lightweight
- simple to understand
- difficult to master

The three pillars:
- transparency
- inspection
- adaptation

Scrum values:
- commitment
- courage
- focus
- openness
- respecct

## Takeuchi, Hirotaka, and Ikujiro Nonaka. "**The new new product development game**". Harvard business review 64, no. 1 (1986): 137-146.
Speed and flexibility are essential.
- The 6 characteristics:
- built-in instability *(often only given a borad end goal)*
- self-organizing project teams
- autonomy = team is free, manegement only provide money
- self-transcendence = establish own goal, guest for "the limit"
- cross-fertilization = teammebmers has different functional specialixations
- overlapping development phases
- "multilearning"
- across multiple levels (individual, group and corporate)
- across multiple functions
- subtle control = "self-control" + "control through peer presure" + "control by love"
- exercised in 7 ways
- selecting the right people for the team
- creating an open work environment
- encouraging, listning to customers
- establis evaluation and reward system on group performance
- managing different rhythms through out the process
- tolerating and anticipating mistakes
- encouraging suppliers to become self-organizing
- organizational transfer of learning

We are loosing the relay race (fx. waterfall model)

Sequential versus overlapping development

Bad things / Problems about overlapping approach:
- communication with the entire project teams
- maintaining close contact with suppliers
- preparing several contingency plans
- handling surprises
- --> more tension and conflict in the group

- require extra effort of all project members
- may not alway result in a breakthrough

## Brooks, Frederik P., and **No Silver Bullet**. "Essence and accidents of software engineering." IEEE computer 20, no. 4 (1987): 10-19.
- There is not silver bullet, there is no way that will work for all kinds of software project
- **Complexity**
- *Communication in a large team*
- *Understanding all posible states of a program*
- **Conformity**
- *Has to conform to the requirements of human clients, which often is inconsisten, not physical laws, when building a brigde*
- **Changeability** [Flexibility]
- **Invisibility**
- *In software progress in not always visible, like when building a bridge - Software Project Management can be seen as a prrocess of making the invisible visible*

## Royce, Winston W. "Managing the Development of Large Software Systems". (1970).
Regardsless of size and complexcity.
**Two essetional steps:**
1. Analysis
2. Coding

If doing a larger software system, you are doomed to fail, if using *the plan*, instead **many additional development steps are required**

**Waterfall method**
1. System requirements
2. Software requirements
3. Analysis
4. Program design
5. Coding
6. Testing
7. Operations

**Iterative waterfall method**
- Ordering of steps:
- each step progresses and the design is further detailed.
- design proceds the change process in scroped down.
- The requirements analysis is completed there exists a firm and closeup baseline.
- Effective fallback position -> maximize the extent of early work that is salvageable and preserved.
> **risky and invites failure!**

### **The FIX**
Step 1: Program design comes first.
- A preliminary program design phase inserted between: software requirements & analysis
- Begin the design process with program designers.
- design, define and allocate the data processing modes.
- write an overview document.

Step 2: Document the design
Step 3: Do it twice
Step 4: Plan, Control, and Monitor testing
Step 5: Involve the customer

## Larman, Craig, and Victor R. Basili. "Iterative and incremental developments. a brief history." Computer 36, no. 6 (2003): 47-56.
**The history of different more or less *iterative and incremental developement models***
- **promotion for using IID methods**

"Iterative development" : merely for rework, in modern agile methods in term implies not just revisiting work, also evolutionary advancement.
- as early as 1957
- Inspired by Extreme Programming
- practice of test-first development: planning & writing tests before each micro-increment.

** "Managing the Development of Large Software Systems"
- actually did not describe, the waterfall model, but an iterative watermodel --> "do it twice" --> just misunderstood by everyone

Then came the spiral model
- great start...

## Coram, Michael, and Shawn Bohner. "The impact of agile methods on software project management." In 12th IEEE = International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS'05), pp. 363-370. IEEE, 2005.**
- **examines the impact of Agile Methods on**
- people
- process
- project
- ***in an attempt to allow project managers (PM) to evaluate the applicability using an agile method - for their project, and choose the right one, if it is***.

Agile methods = enabling teams to more rapidly resond to change
- are costly to accommodate later in the project --> the ability reduces project risks and costs

three types
1. Extreme programming (XP)
- 5 phases = Exploration, Planning, Iterations to Release, Productionizing, Maintenance and Death
2. Scrum
- 3 phases = Pre-game (planning and architecture), Development and Post-game
3. Dynamic System Development Method (DSDM)
- fixes time and resources first --> then adjusts the amount of functionality accordingly

## Herbsleb, James D., and Rebecca E. Grinter. "Architectures, coordination, and distance: Conway's law and beyond." IEEE software 16, no. 5 (1999): 63-70.

**study of globally distributed teams communication**

- being distributed create problems and often ekstra work in, important to coordinate - and communicate
- architecture-based coordination
- plan-based coordination
- process-based coordination
- ad hoc communication (*do not know if someone is avaliable, time difference*)
- knowing whom to contact

## Nerur, Sridhar, RadhaKanta Mahapatra, and George Mangalaraj. "Challenges of migrating to agile methodologies." Communications of the ACM 48, no. 5 (2005): 72-78.
**How difficult it is and all the challenges of swithing to agile methods**
Some are beginning to use Agile methods (Scrum / XP) instead og OO approaches / life cycle based structed (waterfall model / spiral model).
"the balance of agile and plan-driven methods thats fits their situation"

Difference
- grounded in opposing concepts
- changeing impacts the organization
- structure
- cluture
- management practices
- may impact development problems - changing in tools
- rely on people = unpredictability - instead of process
- change in PM role
- before = planner and controller
- now = facilitator, direts and coordinates
- before a lot of documentation -> now lean thinking and cutting down on documentation
- dependent on developers and no mangement
- difficult to find people / developers who want to change to agile methods
- depend more on client, require more from them


Key issues in migrating to agile

## Herbsleb, James D., and Deependra Moitra. "Global software development." IEEE software 18, no. 2 (2001): 16-20.
**Describe the different challenges/issues on being in a GSD - stragical, cultueral, project and process management, technical**

Why globally distributed is accelerated
- capitalize and cost-competitively use resources
- close to marked, locally conditions, locally investment
- improve time to markedet - round the clock development (follow the sun)

**Have evidence of multi-site developement tasks take longer time then co-located tasks - *communication and coordination play a major role in this delay***

- bening distributed does not **only** mean been on different countries, can also mean, different cities, buildings, just at the other end of the corridor = reduces communication

Issues:
- Stategic
- How to divide up the work
- constrained by: resources available, level of expertise, the infrastructure
- The resistance to GSD
- misalignment between senior and middle management
- Many belives *their jobs are threated, experience loss of control, fear need for relocation, need for travel*
- Cultural
- *Require close cooperation between different culturalt backgounds*
- Need for
- structure,
- attitude towards hierarchy,
- sense of time,
- communication style
- can lead to misunderstanding
- Less informal communication
- helps understand what is going on around them, what people are working on, state of different tasks
- Project and process management
- hand off processes between sites
- lack of synchronization
- Technical

## Carmel, Erran, and Ritu Agarwal. "Tactical approaches for alleviating distance in global software development." IEEE software 18, no. 2 (2001): 22-29.

**describe three tactical approaches to reducing intensive collaboration, national and organizational cultural differences, and temporal distance.**

distance create difficulties in coordination and control

1. tactic : reduce intensive collaboration
- coordination complexity

2. tantic : Reduce cultural distance
- oranizational culture
- encompasses the units norms and values (systems developement, methods, project management practices (strict deadlines, high level of documentation))
- nationcal culture
- encompasses ethnic groups norms and values, spoken language
- Bridgehead (75/25 thumb rule)
- 75% personnal work offshore
- 25% personnal work onshore
- optimizes cost savings (offshore), while maintaining closeness the the customer, reducing the cultueral distance.
- Internalization of foreign entity
- internal-to-the-firm = reduces organizational distance, coordination complexity, organizational culture
- Cultural liaison
- A Project manager, who travels back and forth, facilitates cultural, linguistic, and organizational flow of communication (bridge culture, mediate conflicts, resovle cultural misunderstandings) = reduce in both organizational and cultural distance
3. tantic : Reduce temporal distance
- better to have synchronous than asynchronous communication
- fast resolve misunderstandings
- improve quality of life, does not have to compromise personal life to talk with someone in a different timezone
- minimize time-zone difference - compormize with the follow-the-sun type of work
- synchronous = telefoncalls, audio / video conferencing, application sharing, online code walkthrough -> best is face-to-face
- asynchronous = email, voicemail, online discussin groups, project management tools
- Use tools / technology
- all comes with an trade in cost

## Noll, John, Sarah Beecham, and Ita Richardson. "Global software development and collaboration: barriers and solutions." ACM inroads 1, no. 3 (2011): 66-78.

highlight collaboration problems
- collaboration = 4 practices = agreeing, allocating, planning goals, objectives, tasks amoung distributed teams.
how to overcome the barriers = geographic, temporal, cultural, linguistic distance (+ fear and trust) = global distance
- site vistis
- synchronous communication
- knowledge sharing infrastructure to capture implicit knowledge and make it explicit

Models
- Global Teaming Model
- targeted to virtural teams
- takes project management and operational management view
- define global project management
- define management between locations
1. “Identify common goals, objectives and rewards.”
2. “Collaboratively establish and maintain the work product ownership boundaries among interfacing locations within the project or organisation.”
3. “Collaboratively establish and maintain interfaces and processes among interfacing locations for the exchange of inputs, outputs, or work products.”
4. “Collaboratively develop, communicate and distribute among interfacing teams the commitment lists and work plans that are related to the work product or team interfaces.”

Solutions
- address language and cultural differences
- choose similar cultural sites (USA and Ireland)
- develop understanding of different cultures through interaction
- develop a shared organizational culture that comprises shared vision and processes, created by all participates
- promoting trust and overcomming fear
- trust has a big impact on collaboration
- have face-to-face meetings improve trust
- form personal relationships
- lack of awareness can have negative effect on trust and vise versa
- improving communication infrastructure
- synchronous communication, such as video conferencing
- management interventions
- face-to-face meetings
- organizational structures
- choose responsibilities for each site, to reduce coordination with the main development activity
- addressing distributed developement process issues
- chossing appropriate product architecture
- a modular product structure reduces communication overhead
- stable architecture

## Smite, Darja, Marco Kuhrmann, and Patrick Keil. "Virtual teams [Guest editors' introduction]." Ieee Software 31, no. 6 (2014): 41-46

**discuss the benefits and downsides of virtural teams, from three persons view**


globally virtural teams

- virtural team = group of geograhically organizationally and/or time dispersed workers, brought together by information and telecommunication technologies to accomplish one or more ogranizational tasks.
- virtural teams differ fraom traditional collocated teams in that their members remain interdependent when working on their tasks.
- easier to create a common spirit and a shared goal across locations
- network of virtual teams is more stable - increases constancy
- know-how is shared and transffered across locations as a part of teamwork that reduces risks
- specialization in each location - very important
- have virtural collaboration spaces -> simplify and support daily teamwork

- have a truly distributed team - one's opion
- every location perfrom as many team functions as possible
- not split them between places -> leads to silos, negative effect on dynamic and performance
- become more cross-functional
-

# Topics to master for the exam

## Software Project Management
### Why is SPM important?
- Individual approaches, could not keep up
- Software crisis in 1969
- Software engineering in 1968
- A lot of money at stake often in software projects
- avoid failing

### What is a project and its characteristics (+ activities)
* **Project** = a ***planned piece of work*** that is designed to find information about something, to produce something new, or to improve something.
* project is the path that takes us from the current state to the desired state
* **Characteristics**
* Non-routine tasks are involved.
* **Planning is required.**
* Specific objectives are to be met or a specific product is to be created.
* The project has a predetermined time span.
* Work is carried out for someone other than yourself.
* Work involves several specialisms.
* People are formed into a temporary work group to carry out the task.
* Work is carried out in several phases.
* The resources that are available for use on the project are constrained.
* The project is large and complex.
* **composed of a number of related activities**
* start when at least one of the activities are ready to start
* completed when all activities has been complted

#### Activity
- must have a clear start and stop
- should have a duration
- can be forecasted
- some activities are dependent on others to be completed bore they can begin

### Project lifecycle
> **Closing!**

#### Initiation, planning, executing, monitoring, controlling, and closing

##### Company organization models

**formal vs. informal structures**
- formal = staff hierarchy chart
- focus = authority
- informal = contacts and communication, emerges spontaneously between members of staff while working
- takes over when the unexpected happens

**Circular**
- Structure
- outer most circle = entry-level employees, individuals and contributors
- center most circle = highest-level officer
- all divisions seen as part of a whole
- Advantages
- communication / free flow between departments
- spreading vision outward, instead of chain of command
- *more inclusive, and management more accesible*
- Disadvantages
- can be confusing - difficult to find out who to report to
- Best suited
- large organizations where communication between departments are encouraged

**Line**
- Structure
- oldest form of organization + simple
- divided into departments, each with its own responsibilities
- chain of command
- leader at top, with leader for each department beneath
- Advantages
- know precis who to report to - effective communication
- self containing departments, can take own decisions
- Disadvantages
- low to none information structure
- bureacratic
- Best suited
- good for use in large organizations with low use of colloaboration

Others:

##### Roles
General roles in a project
- Client Organization
- Project Manager - of the client
- Project team
- The one with
- decisions and requirements
- controlling and accepting
- has the money
- Contractor Organization
- Project Manager - of the contractor
- Project team with Sub-project managers
- Requirements Engineers
- Architects
- Developers
- Testers
- Agile roles (PO, SM, AC, developers)
- The one with
- responsible for the project
- performs developement
- wants money

##### Activity network diagrams (chp 6), Gantt charts, and critical path

**Activity network diagram**
First estimate the different activities that are required
Then create the diagram.
Then find the longest path = **critical path**
- the fastest we can be done with the project
- labelling convertions
- 
- 

**Gnatt-chart**
Visulasing when the different activites of a project can be done in a calendar.
- concept of time vs activies
- great tool for
- communication
- resource planning
- monitoring progress
- represents a static picture, a single snapshot of the project - Monitoring
- see what activities are ahead or behind schedule

When the project has started and attention is on progress.
- Concerned about 4 shortfalls
- delays in meeting target dates
- critical path activities
- shortfall in quality
- inadequate functionality
- cost going over target
- if not monitoring the execution of the plan, then the plan is pointless

##### The project manager role
- The four parameters, are dependt on each other

- Responsible for
- Achiving project- and contract- goals with the parameters
- Define project "volume"
- Organize and motivate the team
- Create "small succeses"
- Balace the "devels square"
- Manage sub-contractors and vendors
- Organize delivery and acceptace

##### The business case or feasibility study
Rationale for the project, showing benefits of the project outcome, will exceed the costs of development, implementation and operation.

Business Case Document
1. Introduction and background of the proposal
2. The proposed project
3. The market
4. Organizational and operational infrastructure
5. The benefits
6. Outline implementation plan
7. Costs
8. The financial case
9. Risks
10. Management plan

##### Step-wise project planning

- identify products and activities
- estimate effort of each activity
- identify risk for the activities
- allocate resources

Long version:
0. Select project
1. Identify project scope and objectives
2. Identify project infrastructure
3. Analyse project chracteristics
4. Identify project products and activities
5. Estimate effort for each activity
6. Identify activity risks
7. Allocate resources
8. Review / publicize plan
9. and 10. Execute plan / lower levels of planning

##### Risk management
Risk planning is done in -> "analyse project characteristics" and "identify activity risks"

Categories of risk
- Structure = *management structure and systems + affecting planning and control*
- Actors = *all the people involved in the development*
- Technology = *the technology used for implementing and embedded in the delievered products*
- Tasks = *the planned work*

Planning of risks
1. risk identification
2. risk analysis and prioritization
3. risk planning
4. risk monitoring

Risk assessment:
- To find out what is wearth looking in to


Difference approaches for dealing with risks
1. **Risk acceptance** = *we understand the risks, we have identified them, we are not going to do anything about it*
2. **Risk avoidance** = *cannot deal with the risk, not doing the activity, find an alternative*
3. **Risk reduction and mitigation** = *(likelyhood, take precautions to reduce the probability of risk / (impact, take precautions to reduce the impact of risk)*
4. **Risk transfer** = *we know the risk, somebody else is going to handle it*

**Contingency plan / action**
- a planned action to be carried out, if a risk happens

#### Project lifecycle versus development lifecycle

Software development life cycle phases:
- Planning,
- Requirements,
- Design,
- Build,
- Document,
- Test,
- Deploy,
- Maintain

#### SPM versus PM
- There is not silver bullet, there is no way that will work for all kinds of software project
- **Complexity**
- **Conformity**
- *Has to conform to the requirements of human clients, which often is inconsisten, not physical laws, when building a brigde*
- **Changeability** [Flexibility]
- **
- **Invisibility**
- *In software progress in not always visible, like when building a bridge - Software Project Management can be seen as a prrocess of making the invisible visible*

### Method/Process, Plan, Methodology, Practice, and Product

* **Method / Process model** — Abstract representation of a systematic way of accomplishing something (e.g., eXtreme Programming, Scrum (Framework), waterfall).

* **Methodology** — A series of related methods guided by some principles (e.g., Agile methods).
* **Plan** — Implementation of a method.
* *Takes a method --> converts it to real activities*
* *Identify*
* Start and end date
* Who will carry it out
* What tools and materials will be needed

* **Practice** — Reality. The observable implementation of a plan.

* **Product** — “A set of software intensive systems sharing a common and managed set of features satisfying the specific needs of a particular market segment or mission” (Carnegie Mellon Software Engineering Institute)

#### History, definition, and evolution - Software Processes
Not everyone is working agile, there is still dinasours working in different processes.

Every single characteristic of the project / product have to be waited, in order to understand which developement process is the most appropriate one.
*Scrum is the most common, but not nessecary the best one*

Existed since 1970's.
Goal: "get out of software crisis" - systematization of software developement
- Birth of Software Engineering

Software Process
- Definition
- Describes
- Systemtic
- Engineering
- Quantifiable approaches
- Adresses
- Structural organization
- Process organization
- Artifact models
- Questions to aks
- What? Artifact-/product model
- Who? Role model
- How Activity model
- When? Process model, with phases
- Which? Standard tools ect. (typpically from the organization)
- 

Structured methods / models = "get it right the first time"
- consist of sets of steps and rules -> generate system products (such as use case diagrams)
- more time comsuming
- expensive
- pay-off = less error prone and more maintainable final system
- often called *heavyweight methods*

#### Waterfall
Philosopy: Structure follows the sequence of the developement activities.

Very expensive, to go back a change something.

A variant with quality assurence imbedded.

#### Spiral model
Philosopy: Repeat the steps (*define goals -> analyze risks -> evaluate -> plan next iteration*)
Concept: iterative approach
Goal: minimize risk
Key: create prototype for continous test / evaluation


#### Incremental/iterative
Iterative (time-boxing): distribute your time, and deside on how long an interation should be (1 month, 2 weeks, 1 week, 1 year)
Incremental: focus on the product, end of each iteration an version of the product in delivered

***Basis of the most agile methods.***

#### Prototyping
**Two types:**
- **vertically**: slicesing, tackle of presentation layer, application layer, database and so on, until our application stops --> some of the features are prototyped fully
- **horizontal**: mockups of UI --> all features are prototyped but not in detail


#### Rich processes (e.g., RUP)
A rich process is a means of the constructive management. A rich process describes the requirements regarding:
- Software project, Expected outcome, Recommended approach, Responsibilities

Basic Idea:
- Define "global" rules and a seamless description
- Describe ALL (relavant/possible) aspects of software projects
- Artifacts, activities, tasks, roles...
- Dependencies
- Valid and consistent configurations
- GOAL: make "gossip" explicit + define reproducible and testable process descriptions
- avoid implict knowledge, information will survive even if one person gets hit by a truck

**Example - The RUP**
Use lot of UML to describe and document
Not used that much anymore.

#### Agile methods
The methods:
- focus on the code rather than the design
- are based on an iterative approach to software development
- are intended to deliver working software quickly and evolve this quickly to meet changing requirements.

GOAL: *The aim of agile methods is to reduce overheads in the software process* (e.g. by limiting documentation, by fostering communication) and to be able to *respond quickly to changing requirements without excessive rework*.

| Pros | Cons |
| -------- | -------- |
| Change- and feedback- affine | Requires harmony (“feeling blue” syndrome) |
|Client and team are in the spotlight |Requires highly skilled clients and team members |
| Approach is pragmatic and goal-oriented | Availability of the client |
| |Difficult contracting |

## Agile Software Project Management

### History
- Ken Schwaber and Jeff Sutherland worked on Scrum until 1995, when they co-presented Scrum at the OOPSLA Conference in 1995

- Dissatisfaction with overhead involved in software design
- Agile manifesto and agile principles

### Why agile and SPM perspective?
- are intended to deliver working software quickly and evolve this quickly to meet changing requirements.
- Avoid: Change in software is more expensive the later in the process they occur

### Agile methods and techniques
Agile methods = enabling teams to more rapidly resond to change
- are costly to accommodate later in the project --> the ability reduces project risks and costs

three types
- Extreme programming (XP)
- 5 phases = Exploration, Planning, Iterations to Release, Productionizing, Maintenance and Death
- Scrum
- 3 phases = Pre-game (planning and architecture), Development and Post-game
- Dynamic System Development Method (DSDM)
- fixes time and resources first --> then adjusts the amount of functionality accordingly

### Impediments to agile adoption
- No buy-in from management
- Solution: run a pilot to demonstrate the great things about of Agile
- Change in organizational culture and structure
- Often not used to working in a cross-functional team, team-oriented work and product ownership to deliver value.
- Resistance from people who feel they don’t need to change
- Lack of open communication → transparency → awareness
- Solution: work with experienced agile team members or Agile Coach

### Agile KPIs or how to measure success
- Scrum values: Focus, Openness, Respect, Courage, Commitment
- Scrum metrics:
- Measuring deliverables
- Sprint Goal Success
- Escaped defects and defect density
- Team Velocity
- Sprint burndown charts
- Measuring effectiveness
- Time to market
- ROI (return of investment)
- Capital Redeployment
- Customer Satisfaction
- Monitoring the Scrum Team
- Daily Scrum and Sprint Retrospective
- Team Satisfaction
- Team Member Turnover

### Scrum
One common goal

#### Framework
Scrum is under the Agile methods umbrella. Scrum it's self is not a process. An agile process

**Characteristics**
- Self-managing team
- Value is enerated in a series of "sprints" of fixed length of one month or less
- Requirements are captured as items in "product backlog"
- ordered list of what is needed to be improved the product
- No specific engineering practices are prescribed. **It is a general purpose project management framework**
- Uses generative rules to create an agile enviroment for delivering projects
- One of the "agile processes"

**Empricism**
Transparency, Inspection & Asaption

**Values**
Commitment, Focus, Openness, Respect & Coverage

--> TRUST

**Agile Manifesto**

**Agile principles**
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- you delivered an MVP, worked in releases, released new, enhanced versions of the app
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- this is what you have done amazing at compared to some other projects. You were a team from quite early on and you embraced the nenw members too. We did teambuilding to grow even closer together. You respected your colleagues and in such environment, motivation thrives
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
- we tried to simplify complexity, eliminate process waste, work not done in the sense of not moving a shit ton around in documents and tabs, but keeping things simple and in one place + work not done in the sense of not working on user stories that were not there. you had high focus, you knew what you were about to delliver. Some teams are "gold-plating" - meaning adding functionality and stories that were outside the scope, that shows low focus. You did not do that. I could point at a team that did it. So compared to other teams I think you also had very high focus. no anti-patterns there such as the above-mentioned gold-plating phenomenon
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- you have always taken your time to look back at retrospectives and implement what you learned from those from day one of the next sprint; like starting new channels on teams to communicate, or putting in more sketch stories

#### Scrum and change

#### Roles, ceremonies, and artifacts

**Team**
- Product Owner
- Accountable for maximizing the value of the product resulting from the work of the scrum team
- Accountable for effective product backlog management.
- Developing and explicitly communicating the product goal.
- Creating and clearly communicating Product Backlog items.
- Ordering Product Backlog items.
- Ensuring that the Product Backlog is transparent, visible, and understood.
- Scrum master
- Accountable for establishing Scrum as defined in the scrum guide
- Serves the scrum team in several ways, including (coaching, helping, removal of impediments to progress)
- The Scrum Master serves the Product Owner in several ways
- Developers
- 5-9 people --> we were 10!
- Committed to creating any aspect of a usable Increment each Sprint.
- Accountable for:
- Creating a plan for the Sprint, the sprint backlog;
- Instilling quality by adhering to a definition of done;
- Adapting their plan each day toward the sprint goal; and,
- Holding each other accountable as professionals.
- Cross-functional
- Members should be full-time
- Teams are self-managing
-
**Events**
- Sprint
- Typical one month or less
- Fixed duration -> better rhythm
- Product is designed, coded and tested
- Can be cancelled if Sprint Goal become obsolete, by PO
- NO changes during a sprint
- Sprint planning
- Why is this sprint valuable? -> Sprint goal
- What can be Done this sprint? -> Selected PB items
- How will the chosen work get done? -> Plan
- -> Sprint backlog
- Sprint review
- Inspect and adapt on the product
- purpose = insect outcome of the sprint
- teams present the results of their work
- Sprint retrospective
- Inspect and adapt on the process
- purpose = inspect how the last sprint went (interactions, process, tools, DoD)
- Daily scrum
- Purpose
- inspect progress towards sprint goal
- adapt print backlog if necessary
- 15 minutes - standup
- Devlopers and SM
- Improves
- communication
- identify impediments
- promotes quick-decision-making
- consequently eliminate the need for other meetings

**Artifacts**
- Product backlog
- the requirements
- ordered list of what is needed to improve the product
- each item has value to the users of the product
- refined, breaked down and defining to smaller product backlog items
- responsible developers (+ PO)
- **Commitment: The product goal**
- Target for the Scrum team, for all sprints
- Sprint backlog
- -> Sprint backlog
- Why is this sprint valuable? -> Sprint goal
- What can be Done this sprint? -> Selected PB items
- How will the chosen work get done? -> Plan
- A plan for developers
- updated troughout the sprint
- **Commitment: The sprint goal**
- Target for developers for the sprint
- **Making the work visible = burn upchart + burn downchart**
- Increment
- *A concrete stepping stone toward the Product Goal*
- multiple increments may be in a sprint
- Work cannot be considered part of an Increment unless it meets the Definition of Done
- **Commitment: The Definition of Done**

#### User stories
- Try to avoid communication problems regarding software requirements
- Business looses, if one side dominates, either developers or business side
- We will rather have interactions, than processes (Manifesto of Scrum)
- principle nr 6, rather talk face to face = most efficient and effective
- Resource allocation
- need to work together, so it becomes a shared problem
- fails if one side falls too far
- Imperfect schedules
- can not do it perfectly

**Extra terms**
- Theme = a collection of related user stories
- Epic / Saga (/ feature) = a large user story
- INVEST
- 

**Writing user stories**
*"As a (user role), I (want / need/ can/ ect) (goal) so that (reason)"*

**Why user stories**
- Shift focus from writting to talking -> most important!
- Stories are understandable, and easier to remember if turned into stories
- Support and encourage interative development

##### The 3Cs of user stories
- **C**ard
- Stories are tradtional written on note cards
- annotated with esitmates, notes, ect.
- **C**onversation
- detailes behind the story, comes out from speaking with PO
- **C**onfirmation
- acceptance tests, confirm story was coded correctly

#### Backlog grooming / Backlog refinement
Backlog grooming (or refinement) is the act of breaking down and further defining Product Backlog items into smaller more precise items - user stories

### Dual track agile (guest)

### Estimation
#### Estimate size, derive duration
**Size -> Calcultation -> Duration**

Agile measures of size = story points / Ideal days
- Story points
- How long a user story will take (effort)
- Influenced by complexity, uncertainty, risk, volume of work
- Adavantages
- are additive; timebased may not be
- help avoid unit confusion
- Ideal time
- elapsed time is not the same as ideal time --> perfect time, which is not realistic :wink:

#### Velocity and capacity
Velocity = factural metric of how much work has been deliveryed in the sprint
- can be estimated in story points, from all the user stories there is completed
- Not constant
- Useful after some iterations, to measure the expected velocity

Capacity = is an estimate of the total amount of engineering time available for a given sprint.
- can be estimated in story points
- can be estimated from velocity

#### Burn-down charts and burn-up charts

- Burn-down charts
- internal use (SM and developers)
- showing progress in a sprint
- Burn-up charts
- “external use” (stakeholders and PO)
- showing the overall progress of many sprints
- easier to estimate and predict how much work can be done

#### Elapsed time versus ideal time
- Elapsed time
- 2 hours meeting
- 2 hours email
- 4 hours project work
- Ideal time
- Each day 8 hours work
- 40 hours a week
- all you work on, without interruptions and everything you need is available

--> better with story points in estimation
#### Poker planning
Iterative approach to estimation
- reestimating until converge

#### Levels of planning
*The planning onion*

Release planning -> plan over iterations
Sprint plan -> plan over the sprint

**A good plan, is one that support reliable decision-making.**
- "It is better to be roughly right than precisely wrong"

#### Planning in practice

#### Confidence interval
velocity confidence interval = predict how much work a team will complete during a planned number of upcoming iterations, based on previrous sprints velocity, we are better off considering velocity as a range rather than a specific value.
#### Different approaches based on the situation

1. Calculate a confidence interval from historical data
- 90% confidence interval
- Extrapolate from the velocity range
2. Fixed-date planning
1. Determine how many sprints you have
2. Estimate velocity as range
3. Use that range * number of sprints to partotion the backlog into "wil have", "might have", and "wont have"
- -> dertermine what to commit to, balanceing the risk!
- “By that date you will have all of these features and some of these.”
3. Fixed-scope planning
1. Sum the product backlog items
2. Estimate velocity as a range
3. Use that sum of the backlog divded by the velocity range to determine a date ranger
- -> dertermine what to commit to, balanceing the risk!
- “It will take use between 6 and 8 sprints to deliver all those features.”
4. A team with no velocity data
- forecast an initial velocity
- Consider the team
- Establish their velocity
- Turn the point estimate into a range
- Use data from other teans
5. A team changing size
- Track velocity when size changes
- Track across a entire organisation
- Impact of going from fx 6 to 7 people
-

## Working with Teams
### Sourcing and shoring
Sourcing:
- Insourcing = in the same organization in-house
- Outsourcing = delegate to an external company

Shoring:
- Inshoring = when the client is located in the same country
- Offshoring = when the client is located in a different country
- Nearshoring = different countires, but close to each other
- Farshoring = different countries, and far from each other


### The 3Cs collaboration model


### Cooperation, collaboration, communication, coordination, and awareness

### Tools for teams
Collaboration tools: Git, LiveShare
Coordination tools: Kanban-board
Communication tools: Teams

Scrum is also a tool, supporting the different things.
- Daily standup meeting = coordination and communication (+ awareness)

### Communication dichotomies
**Direct vs indirect communication**
- indirect, happens thourgh an artifact = email, documentation, code, commits.

**Formal vs informal communication**

### Computer-mediated communication theories (CMC). *Media richness theory and task/technology fit would be my pick, but feel free to explore the others as well*

Media can be characterized in 3 dimensions of information exchange
1. Time (when)
2. Space (where)
3. Richness (how much)

***Main theories on CMC, here are two, but many more on slides***
**Task/technology fit (TTF)**
- Effectiveness of CMC varies on the type of task
- Rich media do not always provide the best solution for any given task
- Good TTF, when information richness required by the task is proportional to that media

**Media richness theory**
- The more complex the task, the richer the media to use
- Lean media better for certain tasks, rich media better for equivocal (uncertain) tasks

### Mintzberg’s coordination mechanisms

1. Mutual adjustment (coordination of work, via informal communication)
- developers in a scrum team, e.i. daily standup, even though it is not *informal*
2. Direct supervision
- Superviser / boss jobs
3. Standardisation of work processes
- scrum
4. Standardization of output
- RAD + DoD
5. Standardization of skills and knowledge
- certification, education,
6. Standardisation of norms
- dress-code,

### Awareness in CSCW
> “an understanding of the activities of others,
which provides a context for your own activity”
— Dourish and Bellotti

- Workplace awareness
- “the up-to-the-minute knowledge of other participants interactions with the shared workspace”
- Informal awareness
- “the general sense of who’s around and what they are up to”
- Group-Structural awareness
- “knowledge about such things as peoples roles and responsibilities, their positions on an issue, their status, and group processes”;
- Social awareness
- “information that a person maintains about others in a social or conversational context”

## Working with Distributed Teams
### What is Global Software Development? (GSD)
- Global Software Development
- Global Software Engineering
- Distributed Software Development
- Distributed Software Engineering
- Multi-site software development
- Offshoring
- …

Definition:
- “[It] means splitting the development of the same product or service among globally distributed sites.”
- “Software work undertaken at geographically separated locations across national boundaries in a coordinated fashion involving real time or asynchronous interactions”

### Why GSD?
- most talented developers
- development costs
- proximity to market
- time to market
- follow the sun

### Type of distribution
- (Globally) Distributed teams
- *teams in different counties*
- (Globally) Dispersed teams
- *individuels in different countries*
- (Globally) Partially-dispersed teams
- *combination of team and induviduals in different countries*

### Virtual teams
- We are close to (f (c))
- We have been a virtural team!

- We are
- outsoucing = Cisco and ITU
- offshoring = client in different country
- nearshorting = the countries are close geographically

### Challenges of GSD
- Geographical
- Temporal
- diculties in arrangeing meetings
- Cultural -> next semester
- national, individual, company, and so on
- Linguistic -> next semester

### Impact of distances and GSD

- Lack of informal communication due to geographical distance and time-zone differences
- Difficulties with division of work
- Project and process management issues
- Infrastructure problems

### How to alleviate the effect of distances
- Processes
- having an common structed process = relying on it
- ease the need for coordination
- not having a process = you are going to fail if not co-located
- *how much formality ->*
- *distributed need to be more formal?*
- Tools
- use tools!
- maintaining the awareness in the team
- Architecture
- Conways law

**Agile in Global Software Development** (*Paulo thinks it is still possible and a good way, even though some means and logical come the the conclusion that it is not*)
- Tactic 1: Reduce intensive collaboration
- Tactic 2: Reduce cultural distance
- Tactic 3: Reduce temporal distance
- --> increase formal documentation
- --> increate organizational factors such as processes, structure, and goal alignment
- --> waterfall approach
- ***But in reality***
- Close collaborations
- Frequent informal face-to-face communication rather then heavy documentation
- Self-organizing teams
- Peripheral awareness
- Physical artifacts

----
> sometimes better to have distributed team, some mean that you are more productive
> **advantages**
> - reduction in staff cost
> - reduction in overheads
> - if being off-shore staff, when only there when needed, otherwise not employed
> - use specilist instead of general project workers
> - being more productive
>
> **disadvantages**
> - requirements be carefully specified
> - procedures has to be formally expressed
> - coordination maybe more difficult
> - maybe a lack of trust, when never seen your co-workers
>

# More --
# Overview of need topics to master
* Software Project Management
* Why is SPM important?
* What is a project and its characteristics
* Project lifecycle
* Initiation, planning, executing, monitoring, controlling, and closing
* Company organization models (see section 11.11 of the book)
* Roles
* Activity network diagrams, Gantt charts, and critical path
* The project manager role
* The business case or feasibility study
* Step-wise project planning
* Risk management
* Project lifecycle versus development lifecycle
* SPM versus PM
* Method/Process, Plan, Methodology, Practice, and Product
* History, definition, and evolution
* Waterfall
* Spiral model
* Incremental/iterative
* Prototyping
* Agile methods
* Rich processes (e.g., RUP)
* Agile Software Project Management
* History
* Why agile and SPM perspective?
* Agile methods and techniques
* Impediments to agile adoption
* Agile KPIs or how to measure success
* Scrum
* Framework
* Scrum and change
* Roles, ceremonies, and artifacts
* User stories
* The 3Cs of user stories
* Backlog grooming
* Dual track agile (guest)
* Estimation
* Estimate size, derive duration
* Velocity and capacity
* Burn-down charts and burn-up charts
* Elapsed time versus ideal time
* Poker planning
* Levels of planning
* Planning in practice
* Confidence interval
* Different approaches based on the situation
* Working with Teams
* Sourcing and shoring arrangements
* The 3Cs collaboration model
* Cooperation, collaboration, communication, coordination, and awareness
* Tools for teams
* Communication dichotomies
* Computer-mediated communication theories. Media richness theory and task/technology fit would be my pick, but feel free to explore the others as well
* Mintzberg’s coordination mechanisms
* Awareness in CSCW
* Working with Distributed Teams
* Why GSD?
* Type of distribution
* Virtual teams
* Challenges of GSD
* Impact of distances and GSD
* How to alleviate the effect of distances
- Effectiveness of CMC varies on the type of task
- Rich media do not always provide the best solution
- too much or too few = poor TTF