***** [WEBINAR]: RSA what motivates us ***** ***** Team Motivation - [McConnell-1996] Chapter 11 ***** ***** Life Cycle Models - [McConnell-1996] Chapter 7 *****

1. ***** [WEBINAR]: RSA what motivates us *****
If then -> you get that. For simple, straight forward tasks those kinds of incentives are great.
But, when the task gets more complicated, it requires conceptual, creative thinking, so the previous kind of
motivators won't work!
FACT: Money is a motivator. If you don't pay enough, people won't be motivated.
PARADOX: Pay people enough to take the issue of money off the table.
3 factors that lead to better performance and personal satisfaction
AUTONOMY which is the desire to be self-directed (this gets you engagement).
Challenge, MASTERY and making a contribution. It’s an urge to get better at stuff.
More organizations want a transcendent PURPOSE partly because it makes you wanting to go to work and
partly because that's the way they get better talent. When profit motive gets unmoored from purpose
motive, bad things happen.
***** Team Motivation - [McConnell-1996] Chapter 11 *****
Motivation is undoubtedly the single greatest influence on how well people perform.
11.1 Typical Development Motivations
If you want to motivate developers, emphasize technical challenges, autonomy, give a chance to learn and
use new skills, and career planning- respect their personal lives. If you want to appeal to a developer, you'd
better use logical arguments.
11.2 Using the top 5 motivation factors
When people are excited, they will put in long hours and enjoy it.
 Achievement > Provide an environment that makes it easy for devs to focus on what they like going most. If
you let them create their own schedules, they take ownership of their schedules, and you get their buy -in.
For better results, select one objective and make it clear that it is the most important one (not necessarily
have to be simple to work).
 Possibility of Growth > Exciting aspect of being sw dev is working in a field that is constantly changing. An
organization must tap into motivation by providing devs with opportunities to grow on their projects. This
requires aligning the growth goals of the organization with the growth goals of the individual.
 Work Itself > Devs must experience meaning in their work; they must experience responsibility for the
outcome of their work; and they must know the actual results of their work activities. Hackman & Oldham's
five dimensions of work itself that contribute to how meaningful people find their work to be: Skill variety,
Task Identity, Task Significance, Autonomy and Job Feedback. Opportunity to focus on the work itself rather
that other administrative tasks.
 Personal Life > A company can help by realistically scheduling projects so that devs have time for personal
lives, respect vacations/holidays and be sensitive to requests for time off during workday.
 Technical-Supervision Opportunity > Opportunity to supervise technical work implies that the dev has
achieved a level of technical expertise sufficient to direct others.
11.3 Using Other Motivation Factors
> Rewards and Incentives: Important to present any reward purely as a gesture of appreciation rather than an
incentive.
> Pilot Projects: Simple act of conducting experiments, increase productivity.
> Performance Reviews: Once or twice a year, it's a high leverage activity.

2. 11.4 Morale Killers
> Hygiene factors
> Management manipulation
> Excessive schedule pressure
> Lack of appreciation for development's efforts
> Inappropriate involvement of technically inept
management
> Not involving developers in decisions that affect
them
> Productivity barriers
> Low Quality
> Heavy-handed motivation campaigns.
***** Life Cycle Models - [McConnell-1996] Chapter 7 *****
> Pure Waterfall: progresses through an orderly sequence of steps from initial sw concept through system testing.
Project holds a review at the end of each phase to determine whether it is ready to advance to the next phase.
Document driven model. Phases don't overlap. It works well with projects that are well understood but complex.
Disadvantage is difficulty to fully specify requirements at the beginning and it isn't flexible. [Sw Concept>
Requirement Analysis> Architectural Design> Detailed Design> Coding & Debugging> System Testing].
> Code-and-Fix: informal model that's simple, it has no overhead and requires little expertise. [System
Specification (maybe)> Code-and-Fix > Release (maybe)].
> Spiral: Risk-oriented mode, breaks sw proj into mini-projects. It starts small and expands the scope in
increments. It expands only after the risks have been reduced for the next increment to an acceptable level. The
more time and money spent, is less risk being taken. Only disadvantage is that it's complicated.
> Modified Waterfall:
Sashimi> Waterfall w/Overlapping Phases. Reduces documentation and allows more regression. But since there
is overlap among phases, milestones are more ambiguous & it's harder to progress accurately.
Waterfall with subprojects> Careful planning can allow performing some of the waterfall's tasks in parallel. Main
risk is unforeseen interdependences.
Waterfall with Risk Reduction> Risk Reduction spiral at the top of Waterfall to address the requirement risk.
> Evolutionary Prototyping: start by designing and implement the most prominent parts of the program in a
prototype and then adding to and refining the prototype until you’re done. Useful when requirements are
changing rapidly. Disadvantage, impossible to know how long it will take to create an acceptable product.
> Staged Delivery: delivers in successive stages throughout the project. Incremental implementation.
> Design-to-Schedule: develops in successive stages but don’t necessarily know if you’ll ever make it to the last
release. Have to prioritize features and plan so that early stages contain highest-priority features.
> Evolutionary Delivery: develop version of product, show it to customer and refine based on feedback. Draws
from control of staged delivery and flexibility of evolutionary prototyping.
> Design-to-Tools: capability goes into a product only if it is directly supported by existing software tools. If it isn't
supported, it gets left out.