Lecture #1

CS 633 EX
January 23, 2016

Agenda
Course Structure and Expectations
Logistics
One live class, bi-weekly, Saturdays
Term project team meeting
Submissions are due Friday morning

Module 1
Off shoring
Requirements
Engineering Management

Learning Objectives
Upon successful completion of this course, you will be prepared to:

Justify, implement and manage a global product development

Solicit, define and scope requirements as part of the product backlog grooming.
Play an effective role of a Software Engineering Manager in a context of IEEE CSDP
Select an estimation method that is appropriate for a specific phase of a product life
cycle. Oversee adoption of a consistent methodology to narrow the Cone of Uncertainty.
Support the Scrum delivery framework; become aware of several agile certification paths.
Play a role in a peer review, request and provide constructive and concise comments.
Evaluate software development tools (approved, allowed, restricted), while following the
Magic Quadrant technique. Maintain a logical relationship between tools and processes to
optimize their variety throughout an organization.
Articulate the strategy for system and unit test leading to continuous integration and
delivery.
Structure a project asset library aiming at a single-click navigation to a requested artifact.
Provide leadership to a process program using SEI CMMI as an improvement model.

Introduction

Introduction
Focus on learning . You should assume that you will be successful with the course
and hence, grades will be reflective of that. Focus on those best practices that you
learn here and be able to actually apply.
This is an overview course. It delves into multiple topics. Buckle up. You cannot
afford spending all your time on a single topic.
Time box your assignments. This is not about a PhD thesis. This is about becoming
aware of an important concept and then moving to the next concept.
This course is not about a specific language or a framework.
Some assignments and discussions - are optional, aimed to stimulate your thinking
Term project brings it all together. All predefined deliverables of a term project are
introduced in lectures.
How does it all fits together? It is all about how to do software better, about
software engineering and program management. You cannot function as a
professional software engineer or a project manager if you are unaware of these
key concepts covered in the class.

MET
CS473
Principles
Process has no goal in itself

Process
Improvement

Process
A Glue. A Heart bit. A Librarian. Architecture

Data-driven design

Test
Essentials

Mocks are not Stubs

Unit
Test

Deployment pipeline

Continuous
Delivery

Low coupling and high cohesion

Scale optimization

Globalization
Offshoring
Taxonomy

Do not offshore if unable to monetize

Requirements
Backlog
Grooming

If its not on a backlog it does not exist

Engineering
Management

Myth of organizational hierarchy

Software
Configuration
Management

2
4

Estimation

Identification , Control,
Auditing, Reporting
Precision equal to accuracy

Software
Design

Agile

SW Tools
Evaluation

Peer
Reviews

Wisdom of vertical slices

It is cheaper to find defects early

MET
CS473
Responsibilities
Find the shortest path
Separate released from drafts

Select best tests

Unit
Test

Merge each commit

Continuous
Delivery

Requirements
Backlog
Grooming

Process
Improvement

Engineering
Management

Process
Architecture

Test
Essentials

Fail, Pass, Refactor

Globalization
Offshoring
Taxonomy

2
4

Maintain requirements in canonical form

Manage flow of features
Focus your team

Software
Configuration
Management

Document Project Taxonomy

Estimation

Control changes
Retain historical estimates

Fit components into architecture

Software
Design

Agile

Facilitate convergence of tools

SW Tools
Evaluation

Peer
Reviews

Split
Ask for and provide comments

Terminology and
Taxonomy

Terminology and Taxonomy

The purpose of this section is to introduce initial taxonomy and key concepts of
Software Engineering Management.
After completion of this section you should be able to do the following,
establish a mechanism to keep refreshing and clarifying the project taxonomy
become aware of natural hindrances one overcomes while establishing clarity of a
project environment

terminology
taxonomy

Taxonomy

Terminology and Taxonomy

It is the responsibility of a Project Manager, at the beginning of a project, to document key
terms used throughout the product life cycle. Everyone on a project team shall become
clear about the basic concepts and terminology. As Jeff Sutherland puts it in the Scrum
Guide "When a Product Backlog item is described as Done, everyone must understand
what Done means.
We attempt to do follow the same at the beginning of our class.
For us to communicate effectively we need to establish and keep refining with each class
the set of consistent terms. We shall understand each other through the usage and
manipulation of these terms. What is the difference between terminology and taxonomy ?
Terminology defines individual terms. Taxonomy goes much deeper, it explores the
connections and dependencies between various terms, it defines their scope and how
they change over time. We shall always come back to the definition of terms and re-clarify
them.

Engineering
Management

UML

Git

ISO

Test Essentials
Faults & Failures

Cost Of Delay
Black Swan

Requirements

Pivotal
Version
One
Rally

Backlog Grooming

5/20 Rule

Story Points

Architecture

Asset Library

Motivation

Peer Reviews

Defect Density &

Examination Rate

Estimation

Low Coupling and High Cohesion

Quality
Center

Continuous
Delivery

SW Tools
Evaluation

Agile Manifesto

Scrum

CMM

Regression

Cone Of Uncertainty

Software Process
Configuration
Management

MVC

Mocks & Stubs

Unit Test
Process Improvement

Three Trends

There are three trends that dominate the discussion of taxonomy.

First attribute of taxonomy is its unavoidable ambiguity. Take the term "epic" as an example.
It's a bona-fide English word. One might think of a Leo Tolstoy with his multi-volume novels.
In software engineering, the term is used as a high-level requirement that encompass other
low-level stories.
Epic is a so-called special word that have a certain meaning within the boundaries of a
certain projects. At the end of this session there is an assignment to research several
software engineering terms and to overcome their apparent ambiguity.
Second, terms are like coins. After putting them in a circulation, they rub against each other
for a while, and they lose their identity, as their face-value become obsolete. Think about,
how does it happen? what is the mechanics of losing value after an extensive circulation?
Apparently the term "epic" could have many meanings that rub against each other,
so their colloquial meaning become an average of each individual meaning.
Third attribute of many terms is their metaphorical dimension. When Andy Grove titled
his book "Only The Paranoid Survives", he did not imply a literal meaning of a clinical
condition requiring a medical attention. So it is up to a reader to interpret and to apply this
apparent metaphor. When Michael Fagan writes in his paper ... moderator's task is to invite
the phantom inspector... he did not mean to chase after ghosts, but he meant to assure the
team collaborate synergistically. So the task in front of us is to overcome the shallow literal
interpretation and to reach the real author's intent.

The "A"-word
There are certain words around us that are over-used, over-loaded and have started losing
their original meaning. Such an over-exposure is also driven by the key-words approach to
the search of relevant content.
The A Word is a perfect example of such an evolution. Conventional wisdom suggests
that you cannot publish a book or a paper these days without sticking this word inside the
title. It became synonym with the GP Good Practice. For example writing down test
cases or reviewing a project objective is a good thing to do - hence it must be an A Word.
So, unfortunately, we have to stop using this term, since it does not mean anything any
longer; and for all practical purposes it is dead.

Sources of Terms

There are several standard ways to research and clarify the terminology in front of us,
Wikipedia, Margaret Rouse...
.. engineering is the
study and application of
engineering to the design,
development, and
maintenance of
software.

..Continuous software
development is a blanket
term that covers several
aspects of
an iterative..

Off Shoring

Requirements

Requirements Engineering

The module covers responsibilities of sw practitioners involved in managing requirements.

After completion of this section you should be able to do the following,
Position Requirements Management within a broader context
Classify given defect in a requirement statement
Document Roles (users, personas)
Use Canonical Form to develop requirements
Map process workflow into documented requirements

Taxonomy

Requirements Engineering
Elicitation
Analysis
Specification
Validation
Management

Each sub-process is not static. It continues throughout the whole product development.
Context-free Interviewing is a perfect examples of Requirements Elicitation.

Attributes of a Requirements

Following pictorial shows the decomposition of attributes of a requirement. It is useful to create

such a tree when analyzing
the completeness and
Functional Requirements (PRODUCT)
Attributes Tree
quality of all requirements Requirements
Non-Functional Requirements (Constrains) (PROCESS)
for a specific product.
system shall be reliable

the system shall increase a call-center

throughput by 20%

system shall be
user-friendly

the system shall have a probability of

generating a fatal error during any hour
of operation of less than 10(-8)

Attributes of a solid requirement are comprised below.

Unambiguous
Non-overlapping
Complete
Testable
Clearly stated
Consistent
Correct
Modifiable
Prioritized
Traceable & Traced
Uniquely identified
Design-Free

Forbidden Terms
Karl Wiegers [1] has a long list of terms that should be avoided within the language of
a solid requirements. Simply scanning through the list provides a clear direction away
from ambiguity toward a more detailed refinement.

Acceptable
Adequate
Efficient
Fast
Flexible
State-of-the-art
User-friendly
Several
Graceful

Definition of Personas

We should have a clear understanding who is the user of the system we are building. It is
prudent to start the requirements process with documenting the so-called personas (users,
actors, roles). Assuming each persona has a different set of needs, we are aiming to
assemble a complete list of product requirements. R.A.S.C.I. is a common method to define
system roles. There are obvious advantages in providing a consistent definition of roles
across a development organization undertaking several product lines.
ROLES
Task
Submitter Tester Developer Guest Manager
Enter Defects
R
R
R
R
R
Assign User Priority
R
I
I
R
I
Assign Dev Severity
I
C
R
I
A
Resolve Duplicates
I
R
C
I
I
Reproduce Defects
C
R
C
I
I
Provide Fixes
I
I
R
I
I
Retest Fixes
I
R
S
I
I
Close records
I
R
C
I
I
Distribute Reports
I
I
I
I
R
Create assignments and quizzes
Analize Common Trends
I
S
S
I
R
Take quizzes, complete assignments
Grade submissions
R: Responsible
Owns task execution and outcome
Review reports on grading
A: Accountable
To whom "R" is accountable: Respons
Back up the system
S: Supporting
Support the task completion
C: Consulted
I: Informed

Professor Student
R
C
R
I
I

I
R
I
I

Tech. Admin Faculty Dean

C
I
C
I
R

C
I
A
R
A

Has expertize or capability to complete the task

Must be notified of the results, but need not be consulted

Note that definition of personas is a controlled document, since its changes might result in a
significant product ramifications.
In a well-documented case of IBM Shuttle division, software developers display in their cubicles
photos of cosmonauts perished during Apollo 13 mission.

Canonical Form

Canonical form is an established language of defining requirements. It's simple template leading
one to clearly state three parts of a requirement (a) role, (b) action, and (c) value.

Cards from "Braintrust", see above, are commonly used to document product requirements
(stories).
Personas could be both "humans" and "non-humans". In many cases, a key requirement arrives
from interaction with another "software system" in addition to interaction with a certain
"individual".

What's Wrong With These Requirements?

Finding and reviewing defects in someone else's requirements is a great method to avoid
such defects in the future. Pictorial below has a series of common defects.

Pivotal Tracker

https://www.pivotaltracker.com/help/gettingstarted

Individual requirements propagate from right to left, from "Icebox" into "Backlog", then into
"Current" and eventually into "Done." In a traditional environment, one might be
accustomed to a separate Project Plan, Gantt Chart, Tasks beneath Activities, etc. Pivotal
Tracker combines these pieces into a fairly simple dashboard.

Feature Grooming and Scoping

Examine the key software process called Feature Backlog Grooming and Scoping, based on an
example provided below. The swim flow diagram depicts both Grooming and Scoping in
different colors. Grooming deals with feature definition and scoping deals with initial estimation.

Additional context
These swim lanes are taken from a real organization, to clarify the context.
organization consists of approximately 2,000 people
involved 30 architects; 30 product managers; 21 scrum teams
after re-organization from waterfall into agile, 600 test engineers were divided; 200
testers have joined scrum teams and 400 testers remained supporting the system test
revenue generated by this product line exceeds $1B per quarter
there is uninterrupted flow of features proceeding through this process; at any point of
time there are 500 active features in the database
Apparently, the scope of these swim lanes does cover requirements and does not include
development, testing, release, etc.

Description of key activities

You have an exercise covering these swim lanes. Benchmarking is important in developing an
"organizational compassion", a skill to relate to other teams/environments.

To support the notion that requirements are universal, let me bring about an example from a
different area. When you order food in a restaurant, in effect, you provide your "requirements"
to a chef. A waiter has a notebook that is a bona-fide centralized repository of requirements.
And then there is a size estimation, when you match your appetite against the order (five course
meal or a cup of coffee).

Human Factors

What Product Owner feels and should overcome

A feature must be linked to a specific release, a certain team, timeframe , implementation
A feature is simple and could be implemented quickly.
What product Owner should focus on
Product Owner should describe a feature as standing on its own feet and as independent
as possible from other features, considering the difficulty of breaking such dependencies.
A feature should be described without any reference to a timeframe or a projected release
Requirements Management process is like any other process needs a very definite attention
and a discipline. It is not enough to distribute a requirements template with predefined
headings. It is necessary to have a real conversation between all parties involved. To simplify
the exchange, Technical Lead has to ask questions and Product Manager should respond to
these questions. As a result of this conversation Product Manager actually edits the feature
description and assigns a new version.
Everyone should expect to learn something new from Requirements Management process.
Tech Lead will learn about the feature so to pave the way to next implementation steps. PM is
bound to learn from responding to various questions and from reducing to paper these
responses.

Practice Assessment
Six organizations were benchmarked regarding their requirements process. The following scenarios (interviews of
software engineers) were recorded during an assessment. Based on these testimonies, rank each company, from least
mature to the most mature. Supplement your ranking with a one-line justification.
Testimony 1
A product manager bumps into a software engineer in a crowded subway and whispers into his ear a new requirement.
Software engineer has no chance to respond since he has to get off the train to drop his two-years old to a
kindergarten. Within next hour, PM commits this requirement to a customer who expects it to be installed Wednesday
at 9:45 pm.
Testimony 2.
A company president walks into the weekly meeting of a project team. He announces an emergency customer request
with all-hands on deck. Everyone has to drop whatever he / she are doing and to engage with implementing a new
feature for the upcoming show in Vegas.
Testimony 3.
Requirements are kept in a unified repository with multiple attributes. There is a consistent set of states for each
requirement, as it advances along a product life cycle. Requirements are reviewed using a standard peer review
process, involving architects and testers.
Testimony 4.
Every Friday, for an hour or so our project team gets together in a caf. We brainstorm new requirements and then go
to our individual cubicles and start implementing these requirements right away. Next Friday we resume the
brainstorming.
Testimony 5.
Product Managers are not allowed to provide details or elaborate on requirements. Their interaction with us is time
boxed to 3 minutes. We are not engineers, we are ARTISTS. We must guess, extrapolate, and fantasize. We are not
asking questions. Our process stimulates an "artistic" approach to software design. We are not complying with anyone's
requests; we breathe software life into the cold machines.
Testimony 6.
We plan our requirements as stories for one iteration only. Product owner ranks the backlog covering multiple
iterations. Customer value drives the ranking. Architects contribute their requirements to the same product backlog.

Possible Responses
Company (3) and (6) stand out with their meaningful process. Other companies have
apparent issues that need to be addressed.
(1) requirements are not documented
(2) product owner is bypassed
(4) requirements are not ranked&approved
(5) users are ignored and customer value does not come into a picture
Additional considerations, while looking at the same glass that is half full
(1) Fast delivery is what any company is striving for. The process here is quick and simple to
the bone; what else would you want?
(2) Bean counting is the only thing many presidents do. Their only worry is the financial
bottom line. This president is different. He actually knows the product and its features. He is
confident and in command.
(3) One of the biggest advantages of a unified repository is the ability to copy requirements
from one release to another. A huge simplification.
(4) Sign me up for this team. These guys are jelled, they are together, they collaborate and
help each other.
(5) Steve Jobs famously posed the question ...
Do customers really know what they want?
(6) When architects contribute their changes through the same pipeline,
it is a sign of a certain maturity.

When assessing several teams, it is important to converge on a consistent list of criteria.

Below is the so-called Assessment Instrument, that employs a consistent criteria checklist.
The same template could be used as an organizational adoption chart. Starting with the first
line item 'requirements are documented', we could assess each team, where they stand
regarding the requirements process.
Assessment Instrument
adoption chart
CRITE RIA

Team Team Team Team Team Team

1
2
3
4
5
6

Requirements Documented

No

No

Yes

No

No

Yes

Requirements Controlled

No

No

Yes

No

No

Yes

Requirements reviewed
including architects&testers

No

No

Yes

Yes

Yes

Yes

Requirements Approved

No

No

Yes

No

No

Yes

Pictorial below illustrates the application of a

consistent criteria across multiple projects. It
explores the notion of a process maturity.
Various practices are positioned at certain
maturity levels. At Level A none of the seven
given practices are used. At Level D all
practices are adopted.
Maturity Paradigm
Requirements Engineering
7

Customer Value Drives

Ranking

Yes

No

Yes

No

No

Yes

Status & Metrics Distributed

No

No

Yes

No

No

No

Common Process Effective

Yes

Yes

Yes

Yes

Yes

Yes

Level D
Level C

Level B

4
3
2

Level A

Requirements
Documented

Requirements
Controlled

Requirements
review ed including
architects&testers

Requirements
Approved

Customer Value
Drives Ranking

Status & Metrics

Distributed

Common Process
Effective

Engineering
Management

Engineering Management
The purpose of this section is to delve into selected aspects of engineering management.
Software engineers often ask - what do managers do? In a context of our course, it is
important to shed some light on presumed responsibilities of a software leader.

perform a function of a manager / generalist

align company culture with project goals
establish consistent development process
leverage organizational cause and effect relationships to optimize product delivery
motivate software engineers
avoid excessive multitasking
maintain software development policies

Taxonomy

Universality of software management

Process consistency
Organizational culture
Cost of a defect
Maslow Motivation Model (MMM)

Universality and Specifics of Software Management

A software manager is bound to perform the same tasks as any other non-software manager.
The universality of management with its five aspects - is reflected on the diagram below.

A software manager is supposed to master some definite expertise in these five aspects.
Planning - Predetermining a course of actions for accomplishing organizational objectives
Organizing - Arranging the relationships among work units for accomplishment of
objectives, and granting of responsibility and authority to obtain those objectives.
Staffing - Selecting and training people for positions in the organization
Directing - Creating an atmosphere that will assist and motivate people to achieve
desirable result
Establishing, measuring, and evaluating performance of activities toward planned
objectives

Specifics of Software Management

Perception of clients of a lack of appreciation for inherent complexity
1 and profound ramifications of requirements changes

Software process itself generates a need for changes in client

requirements

3 Software is often built as an iterative process

4

Software engineering maintains a difficult balance between creativity

and discipline

5 Software engineering is largely lacking an underlying theory

6 Software is intangible and is difficult to test
7 Degree of software novelty and complexity is extremely high
8 Software Engineering is faced with extremely high degree of change

Organizational Culture

Any introductory module needs to cover a concept of a company culture.

What is a company culture? It is a set of assumptions and unwritten rules that guide
individuals in their day-to-day activities. Those, who have been with the company for a while,
have already became a part of the culture. However, those who just arrived need to answer
many questions.
Do people sit all together in the cafeteria or separately?
When should men wear ties and women suits?
What are the consequences of not delivering product on-time?
Will my boss be mad at me if customers find a bug in my code?
Aligning company culture with the company mission is an important management task.
The blue-suit strictly hierarchical culture of IBM is very different from the free-wheeling, grab
market first culture of Facebook. Both of these very successful companies enjoy and prosper
because of their strong culture.
A question in front of a manager is ... How to
transition a documented Best Practice into a
company culture, push it into fabric, make it stick?
How to align the Culture with project goals?
It is a responsibility of a manager to become
Aware of various company's cultures, compare
and perform the "mental benchmarking",
so to be able to act accordingly.

Consistent Process (horizontally and vertically)

Consistency is the fundamental attribute of a mature software process. Pictorial below

focuses on a distributed aspect of software development. Note that two processes do
not need to be identical in order to be consistent. Apparently, it is impossible to develop
and deliver a common product across multiple continents,
if the overall process is inconsistent.
In a context of a geographically
Site
Location
# Employees
Product Specialty
distributed team, an example of a
Headquarters
Brookline
85
..
Site 1
Stockholm
40
..
severe inconsistency would be ...
Site 2
San Francisco
20
.
Site 3
Manhattan
10
.
product manager documents
Site 4
Paris
5
.
ambiguous requirements in
Brookline, resulting in testers in
Paris unable to verify certain
aspects of product features.

Policies

Consistency across organizational levels is

equally important. It would be unproductive
to have a gap between a top level direction
provided by Senior Management and a
bottom level product implemented by
engineers.

Sr.
Management
Project
Managers

Standardized Project Plans

Software Developers
Test Engineers

SCM
Inspections
Test Cases

A Myth of Organizational Hierarchy

When you are sitting in front a blank sheet of paper trying to capture a key thought that is both
elusive and fundamental, the idea of you reporting to someone else - seems so irrelevant. What
difference does it make how many organizational levels are above you or below you? How could
it possibly help with solving the task at hand? In fact, it does not.

Having said this, it is still important

to consider various org charts.
Since when people talk about an
"organization" they usually mean
the "org chart". Here is the chart
of a so-called matrix organization.

It is a natural tendency to flatten the hierarchy, to open up barriers and shorten communication
paths. Although, realities of a software company teach us differently. Managers do own a
certain function that must be accomplished one way or another.
Reading about companies that grew quickly, e.g. Akamai, Google, we learn that, at some initial
point, a senior manager decided to abandon a hierarchy and make a large group of people
reporting directly to him. Such decision could go only so far. Eventually a certain structure had to
be put in place.

Staying Close To Reality and Value

It is not coincidental that the name of the biggest yearly conference in Bay area with
participation of CEOs of largest companies - is "The Code"
While navigating around a big organization, with everything that is going on, let me
confirm that "The Code" is the only reality you and I could possibly share. Understanding
what is real what is not real - is a key skill of a professional software manager.
With all my appreciation for peer reviews, I should confirm that the idea of sitting around a
table and examining some mental models looks like a fantasy in comparison with real test
defects revealed while exercising the actual system.
Agile Principle # 7 states that "...
working software is the primary
measure of a project progress ... ".
one story
It is not the number functional
Who What Why
specs written, not the number
of management reviews,
but the software itself is the
measure.
one story
Who What Why

Organizational Value
Release
Value
Sprint
Value

Organizational Cause and Effect Relationships

Examine notation introduced by Gerry Weinberg in his book "Systems Thinking".

A blue triangle designates a positive correlation.
Red circle denotes a negative correlation.
We should traverse the diagram to make sure the relationships between all areas are clear. I
observed in many small and medium-size companies, that both green areas are managed by
the same person/role, for example, by a Quality Assurance Director.
.

Motivational Models

A software manager motivates team members. It is important to distinguish a good

motivational strategies that support the long-term organizational objectives. On a contrary,
applying a poor strategy could de-motivate engineers or create a conflict that is bound to
destroy a team.
Maslow hierarchy is worth pondering.
While managing an off shoring team in India, one day I heard that folks are unable to come
to the office. This is because software engineers were afraid for their lives, due to an unrest
in their remote province. Looking at the Maslow hierarchy, I see "safety" belongs to the
second level. Although, assuring "safety" for engineers in Boston would hardly be an
appropriate motivator. Since those needs that have been satisfied already are no longer a
motivator.
Motivation Model

Facilitating a learning
environment, where folks
are able to unleash their true
potentials - is the
motivational strategy
belonging to the top level
of Maslow hierarchy.

Elaboration

Frederick Taylor

Workers will respond to an incentive wage

Elton Mayo

Interpersonal (group) values override individual values

Kurt Lewin

Group forces can overcome the interests of an individual

Douglas McGregor

Managers must understand human nature in order to motivate them

Maslow

Human needs can be characterized in a hierarchy. Satisfied needs

are not motivators.

Fredrick Herzberg

A decrease in environmental factors is dissatisfying; an increase in

environmental factors is NOT satisfying. A decrease in job content
factors is NOT dissatisfying; an increase in job content factors is
satisfying

Chris Argyris

The greater the disparity between company needs and individual

needs, the greater the employee's dissatisfaction

Rensis Likert

Participant management is essential to personal motivation

Arch Patton

Executives are motivated by the challenge of work, status, the urge

to achieve leadership, the lash of competition, fear, and money

Theory Z

A combination of American and Japanese management style.

People need goals and objectives; otherwise they can easily impede
their own progress and the progress of their company.

Total Quality Management (TQM)

A strategy for continually improving performance at each level and

area of responsibility

SelfActualization
Esteem and
Recognition
Social Needs
Security and Safety
Biological Survival

Many motivational models suggest "taking money off the table" so to speak. Here is the
link to an insightful video with Dan Pink saying that The best use of money as a
motivator is to pay people enough to take the issue of money- off the table. Your
assignment illustrates this notion further.
Motivational strategy responds to a "Why" question. This is the second order question,
considering the "What" being the first order. As many folks first learn what they are
supposed to accomplish (e.g. obtain a university degree) and then become fully aware of
why they are engaged in a degree program.
Consider several individual motivations to obtaining a degree. It is important we map them
into the MMM Hierarchy.
Fear of failing the course and losing paid tuition
Fear of being unable to get a job and support basic needs
Fear of getting a poor grade, being rebuked by a supervisor and ridiculed by peers
Desire to get a new job through a better resume
Desire to learn new skills and broaden knowledge
Desire to apply new techniques at current work
Desire to stay current, as a personal interest, without a specific plan to apply new skills
Should note the personal aspect of motivation..
In agile, the greatest motivation is peer pressure. A poor performer, who is unable to share
the load, will be surely dismissed by a scrum team.