SE 477 Software and Systems Project Management

1
SE 477 Software and Systems Project Management

• Dennis Mumaugh, Instructor
• dmumaugh_at_cdm.depaul.edu
• Office CDM, Room 429
• Office Hours Tuesday, 400 530

2
Administrivia

• Comments and feedback
• Lectures?
• Work Load?
• Reading?
• Progress
• Project
• Journal

3
Assignment 4

• We want to concentrate on the computing
  environment. Major risks are
• Loss of time due to system or part of system down
• Loss of configuration files renders system
  unworkable
• Loss of hardware (bad computer, bad drives)
• Loss of source files (disk corruption)
• Loss of network (see 1 above)
• Loss of work (aka source code) and need to
  rewrite code
• Backups essential
• Use RAID for critical disks tape for all
  off-site backups for disaster
• The rest of the story About a week after the
  last person left, there was a system crash that
  caused major problems. See note page for
  details.

4
SE 477 Class 9

• Topics
• Miscellaneous
• Agile Project management
• Project management anti-patterns

5
Thought for the day

• The only way to get bad decisions is to make all
  of them yourself.

6
Last time

• Miscellaneous
• Quality control planning and assessment and
  project tracking
• Configuration management and change control
• Stakeholder management
• Final stages
• Rollout
• Migration
• Project recovery
• Defining project success and failure
• Success tips

7
Agile DevelopmentAgile Project Management
8
Readings

• ScrumReferenceCard/http//ScrumReferenceCard.comS
  crumReferenceCard.pdf
• Pernicious Scrum Anti-Patterns http//www.drdobbs.
  com/architecture-and-design/pernicious-scrum-anti-
  patterns/240168658

9
Agile Software Development

• Software development methods
• Requirements and solutions evolve
• Collaboration between self-organizing,
  cross-functional teams.
• Features
• Adaptive planning,
• Evolutionary development,
• Early delivery,
• Continuous improvement
• Encourages rapid and flexible response to change.

10
Overview

• There are many specific agile development
  methods. Most promote development, teamwork,
  collaboration, and process adaptability
  throughout the life-cycle of the project.
• Iterative, incremental and evolutionary
• Efficient and face-to-face communication
• Very short feedback loop and adaptation cycle
• Quality focus

11
Iterative, incremental and evolutionary

• Most methods break tasks into small increments
  with minimal planning and do not directly involve
  long-term planning.
• Iterations are short time frames (timeboxes)
  last from one to four weeks.
• Involves a cross-functional team working in all
  functions planning, requirements analysis,
  design, coding, unit testing, and acceptance
  testing.
• A working product is demonstrated to
  stakeholders.
• Minimizes overall risk and allows the project to
  adapt to changes quickly.
• Goal is to have an available release (with
  minimal bugs) at the end of each iteration.
• An iteration might not add enough functionality
  to warrant a market release
• Multiple iterations might be required to release
  a product or new features.

12
Efficient and face-to-face communication

• Each agile team will contain a customer
  representative, e.g. Product Owner in Scrum.
• This person is appointed by stakeholders to act
  on their behalf
• Makes a personal commitment to being available
  for developers to answer mid-iteration questions.
  
• At the end of each iteration,
• Stakeholders and the customer representative
• Review progress
• Re-evaluate priorities
• An information radiator physical display
  located prominently in an office,
• Presents an up-to-date summary of the status of a
  software project or other product

13
Very short feedback loop and adaptation cycle

• A common characteristic are daily status meetings
  or "stand-ups", e.g. Daily Scrum (Meeting).
• team members report to each other
• what they did the previous day,
• what they intend to do today
• what their roadblocks are.

14
Quality focus

• Specific tools and techniques are often used to
  improve quality and enhance project agility, such
  as
• Continuous integration,
• Automated unit testing,
• Pair programming,
• Test-driven development,
• Design patterns,
• Domain-driven design,
• Code refactoring

15
Scrum

• Within agile development, Scrum has the most to
  say about exactly what is agile project
  management. So lets use Scrum as our model for
  answering this question.

16
Scrum
http//en.wikipedia.org/wiki/ImageRugby_union_scr
ummage.jpg
http//www.controlchaos.com
17
Scrum

• Developed by Ken Schwaber and Jeff Sutherland
• Name derived from Rugby
• Group effort to move quickly to counter the
  opposite team, adjusting the move along progress
• Divides a project into iterations (sprints) of 30
  days
• Sprint 30 days iteration cycle with pre-sprint
  and post-sprint activities
• Define functionality for sprint
• Leave team alone to deliver
• Sprint Goal minimum success criterion to steer
  and keep focus

18
Scrum Lifecycle

• Planning
• Vision, expectations, funding
• Staging
• Identify requirements, prioritize iteration
• Development
• Implement system ready for release in each sprint
• Release
• Operational deployment

19
Scrum

• Leaves documentation depth to specifics of
  projects may need more or less
• aim for as little as possible
• Self-directed and self-organized team
• Competent focused people
• Demo to stakeholder at iteration end
• Client-driven adaptive planning
• No work added during iteration
• Lends itself to experimenting on certain parts of
  the application development

20
Scrum Values

• Commitment
• Team takes responsibility to complete the Sprint.
  To avoid things that will stand in its way
• Focus
• Teams focus is maintained. Distractions,
  interruptions are fielded
• Openness
• Overall and individual status and commitments
  kept open.
• Respect
• Team responsibility rather than scapegoating.
• Courage
• Management and team have the courage to take
  responsibility to do what is necessary

21
Agile Project Steps

1. The product owner identifies the product vision.
2. The product owner creates a product roadmap.
3. The product owner creates a release plan.
4. The product owner, the (scrum) master, and the
   development team plan sprints, also called
   iterations, and start creating the product within
   those sprints
5. During each sprint, the development team has
   daily meetings called scrums.
6. The team holds a sprint review.
7. The team holds a sprint retrospective.

22
Agile Project Artifacts

1. Product vision statement An elevator pitch, or a
   quick summary, to communicate how your product
   supports the company's or organization's
   strategies. The vision statement must articulate
   the goals for the product. Revisit once a year.
   See slides 38-39 lecture 3.
2. Product roadmap The product roadmap is a
   high-level view of the product requirements, with
   a loose time frame for when you will develop
   those requirements. Revisit twice a year.
3. Release plan A high-level timetable for the
   release of working software.
4. Product backlog The full list of what is in the
   scope for your project, ordered by priority. Once
   you have your first requirement, you have a
   product backlog.
5. Sprint backlog The goal, user stories, and tasks
   associated with the current sprint.
6. Increment The working product functionality at
   the end of each sprint.

23
Agile Project Roles

1. Development team The group of people who do the
   work of creating a product. Programmers, testers,
   designers, writers, and anyone else who has a
   hands-on role in product development is a member
   of the development team.
2. Product owner The person responsible for
   bridging the gap between the customer, business
   stakeholders, and the development team. The
   product owner is sometimes called a customer
   representative.
3. Scrum master The person responsible for
   supporting the development team, clearing
   organizational roadblocks, and keeping the agile
   process consistent. A scrum master is sometimes
   called a project facilitator.
4. Stakeholders Anyone with an interest in the
   project.
5. Agile mentor Someone who has experience
   implementing agile projects and can share that
   experience with a project team. The agile mentor
   can provide valuable feedback and advice to new
   project teams and to project teams that want to
   perform at a higher level.

24
Agile Project Events

• Project planning The initial planning for your
  project.
• includes creating a product vision statement and
  a product roadmap,
• can take place in as little time as one day.
• Release planning Planning the next set of
  product features to release
• Sprint A short cycle of development, in which
  the team creates potentially shippable product
  functionality.
• Sprint planning A meeting at the beginning of
  each sprint where the scrum team commits to a
  sprint goal.
• Daily scrum A 15-minute meeting held each day in
  a sprint, where development team members state
  what they completed the day before, what they
  will complete on the current day, and whether
  they have any roadblocks.

25
Agile Project Events

1. Sprint review A meeting at the end of each
   sprint, where the development team demonstrates
   the working product functionality it completed
   during the sprint.
2. Sprint retrospective A meeting at the end of
   each sprint where the scrum team discusses what
   went well, what could change, and how to make any
   changes.

26
Scrum

• Scrum iterations are called sprints and last no
  more than one month
• Sprints are time-boxed they are never extended,
  but may be restarted
• Scrum de?nes three roles
• The product owner is responsible for managing the
  product feature list
• The team does the work
• The scrum master facilitates the scrum process
  the scrum master is not a conventional project
  manager
• Scrum produces an executable, potentially
  shippable product increment at the end of each
  sprint
• Potentially shippable means done in the scrum
  sense all commitments for the sprint have been
  metno its 80 done is allowed
• This demonstrates value iteratively to the
  product owner and to other stakeholders

27
The Sprint Cycle

• Planning meeting at the start of the sprint
• During the sprint, team members attend a daily
  Scrum meeting,
• At the end of the sprint, there is a sprint
  review
• At the end of each sprint is the sprint
  retrospective.

28
Meetings

• Scrum has five meetings
• Backlog Grooming (aka Backlog Refinement),
• Sprint Planning,
• Daily Scrum (aka 15-minute standup),
• the Sprint Review Meeting,
• and
• the Sprint Retrospective Meeting.

29
Scrum Meetings

• Planning meeting
• Sprint
• Scrum meeting
• Sprint review
• Sprint retrospective

30
The Sprint

• Planning meeting at the start of the sprint
• create a sprint backlog a list of the tasks to
  perform during the sprint.
• During the sprint, the team takes a small set of
  features from idea to coded and tested
  functionality.
• At the end, these features are done, meaning
  coded, tested and integrated into the evolving
  product or system.

31
Backlog

• Backlog used for planning
• Complete functionality that remains to be added
  to the product.
• Features and estimate of duration for each task
• Tasks for sprint picked from the pool of tasks
• Used to decide features for sprint and plan out
  the work

32
Scrum

• Every day the team holds a short (fifteen minute)
  meeting, called a scrum,
• Scrum meeting Short standup meeting to
  communicate and monitor progress
• Daily scrums as a way to synchronize the work of
  team
• share what they worked on the prior day,
• The team runs through what it will do in the next
  day
• Surfaces roadblocks
• Some recommend all participants stand
• Scrum Master coach for the team
• Looks outward keeping distractions out
• Trusts the self-managed team to get work done

33
The Sprint

• The Sprint Review
• The team demonstrates the new functionality to
  the PO or any other stakeholder who wishes to
  provide feedback that could influence the next
  sprint.
• This feedback loop within Scrum software
  development may result in changes to the freshly
  delivered functionality, but it may just as
  likely result in revising or adding items to the
  product backlog.

34
The Sprint

• The sprint retrospective is at the end of each
  sprint. The whole team participates in this
  meeting, including the Scrum Master and PO.
• The meeting is an opportunity to reflect on the
  sprint that has ended, and identify opportunities
  to improve.
• The team reflects on its own process. They
  inspect their behavior and take action to adapt
  it for future Sprints.
• A common impediment to full transparency on the
  team is the presence of people who conduct
  performance appraisals.
• Retrospectives often expose organizational
  impediments.

35
Agile Project Management
36
What is Agile Project Management?

• Most agile processes - Scrum in particular - do
  not include a project manager.
• Agile project manager roles and
  responsibilities are distributed among others on
  the project, namely the Team, the Scrum Master
  and the Product Owner.

37
Topics

• How are Agile Projects Managed?
• Where Does the Scrum Master Fit in Agile Project
  Manager Roles and Responsibilities?
• Who Handles Conventional Project Manager Duties
  in Agile Development?
• Do Agile Projects Scale with Agile Project
  Management?

38
How are Agile Projects Managed?
39
Scrum

• On a Scrum project, there are three roles
• Product Owner
• Team
• Scrum Master

40
The Product Owner

• Responsible for the business aspects of the
  project, including ensuring the right product is
  being built, and in the right order.
• Balance competing priorities,
• Available to the team,
• Empowered to make decisions about the product.
• Single person responsible for maximizing the
  return on investment (ROI) of the development
  effort
• Responsible for product vision
• Constantly re-prioritizes the Product Backlog,
  adjusting any long-term expectations such as
  release plans
• Final arbiter of requirements questions

41
The Product Owner (cont)

• Accepts or rejects each product increment
• Decides whether to ship
• Decides whether to continue development
• Considers stakeholder interests
• May contribute as a team member
• Has a leadership role

42
The Team

• Cross-functional (e.g., includes members with
  testing skills, and often others not
  traditionally called developers business
  analysts, domain experts, etc.)
• Self-organizing / self-managing, without
  externally assigned roles
• Negotiates commitments with the Product Owner,
  one Sprint at a time
• Has autonomy regarding how to reach commitments
• Intensely collaborative

43
The Team (cont)

• Most successful when located in one team room,
  particularly for the first few Sprints
• Most successful with long-term, full-time
  membership. Scrum moves work to a flexible
  learning team and avoids moving people or
  splitting them between teams.
• 7 2 members
• Has a leadership role

44
The Scrum Master

• Facilitates the Scrum process
• Helps resolve impediments
• Creates an environment conducive to team
  self-organization
• Captures empirical data to adjust forecasts
• Shields the team from external interference and
  distractions to keep it in group flow (a.k.a. the
  zone)
• Enforces timeboxes
• Keeps Scrum artifacts visible
• Promotes improved engineering practices
• Has no management authority over the team (anyone
  with authority over the team is by definition not
  its Scrum Master)
• Has a leadership role

45
The Scrum Master

• Unlike a traditional project manager, the Scrum
  Master is not viewed as the person to credit (or
  blame) for the success (or failure) of the
  project.
• The Scrum Master's authority extends only to the
  process. The Scrum Master is an expert on the
  process, and on using it to get a team to perform
  to its highest level.
• A Scrum Master does not have many of the
  traditional responsibilities scope, cost,
  personnel, risk management that a project
  manager does.

46
Summary

• One way to think of the interlocking nature of
  these three roles in Scrum is as a racecar
• The Scrum team is the car itself, ready to speed
  along in whatever direction it is pointed.
• The product owner is the driver, making sure that
  the car is always going in the right direction.
• And the Scrum Master is the chief mechanic,
  keeping the car well tuned and performing at its
  best.

47
Role of Project Managers

• Agile distributes the traditional project
  manager's responsibilities
• Task assignment and day-to-day project decisions,
  revert back to the team,
• Responsibility for scope and schedule tradeoff
  goes to the product owner.
• Quality management becomes a responsibility
  shared among the team, a product owner and Scrum
  Master.
• Other traditional tasks are distributed as well

48
Scaling Agile Projects

• Agile processes like Scrum are definitely
  scalable. While the typical agile project has
  between five and 20 people across one to three
  teams, agile implementation has been successful
  on projects with 200 to 500 even 1,000 people.
• As you might expect, projects of that size must
  introduce more points of coordination and agile
  project management than small-scale
  implementation.
• To coordinate the work of many teams, larger
  projects sometimes include a role called project
  manager. While involving someone on the project
  with this title or background can be very
  helpful, we need to be careful of the baggage
  associated with the project manager title.

49
Scaling Agile Projects

• Even on a very large agile project, the team will
  still do much of the project management. For
  example, teams decide how to allocate tasks, not
  a project manager so the project manager role
  becomes more of a project coordinator.
• Duties would include allocating and tracking the
  budget communicating with outside stakeholders,
  contractors and others maintaining the risk
  census with guidance from the teams, Scrum
  Masters and product owners and so on. This is a
  true agile project management role.

50
Thought for the day

• We have met the enemy and he is us.
• Pogo

51
AntiPatterns
52
Readings

• Anti-patterns
• AntiPatterns, Brown, William J., John Wiley and
  Sons, 1998, ISBN 0-471-19713-0, see especially
  chapter 7
• Project Management AntiPatterns
  http//sourcemaking.com/antipatterns/software-pro
  ject-management-antipatterns
• 5 Common Antipatterns in Software Project
  Managementhttp//codebuild.blogspot.com/2012/06/5
  -common-antipatterns-in-software.html

53
What is a pattern

• In software engineering, a design pattern is a
  general reusable solution to a commonly occurring
  problem within a given context in software
  design.
• It is not a finished design that can be
  transformed directly into source or machine code.
  
• It is a description or template for how to solve
  a problem that can be used in many different
  situations.
• Patterns are formalized best practices that the
  programmer can use to solve common problems when
  designing an application or system.

54
What is an AntiPattern

• Anti-patterns are certain patterns in software
  development that is considered a bad programming
  practice.
• As opposed to design patterns which are common
  approaches to common problems which have been
  formalized, and are generally considered a good
  development practice, anti-patterns are the
  opposite and are undesirable.

55
Patterns vs. AntiPatterns
56
Anti Pattern Template

• AntiPattern Name name
• Type Design Organizational ...
• Problem what you really want to solve present
  a simple concrete example
• Context context
• (unbalanced) Forces forces
• Root Causes
• General Form
• Symptoms and Consequences the bad solution
  explain in terms of your concrete example

57
Anti Pattern Template

• Resulting Context what happens when you apply
  it, good and bad
• Seductive forces why this is so popular
• Why, despite the seductiveness, this is actually
  a BadThing
• Replacement positive patterns
• Design Rationale rationale
• Related AntiPatterns
• Applicable Positive Patterns
• AntiPattern Category classify it
• Also Known As other names

58
Root causes

• Haste
• Apathy
• Narrow-Mindedness
• Sloth
• Avarice
• Ignorance
• Pride (NIH)

59
Primal Forces

• Management of Functionality
• Management of Performance
• Management of Complexity
• Management of Change
• Management of IT resources
• Management of Technology Transfer

60
How to describe AntiPatterns

• The AntiPattern Template should include a section
  to say what is wrong with it. If not, there is
  the risk to be reading some of these
  anti-patterns and
• forget half-way through that it is an
  anti-pattern, and start reading it as a positive
  pattern,
• try to figure out what is wrong with it, and not
  doing very well. One couldn't tell if the
  Rationale is the "pseudo-rationale which a faulty
  thinker would think causes this to be a valid
  pattern", or "the rationale about why this is an
  anti-pattern".

61
Project Management AntiPatterns

• Blowhard Jamboree
• Analysis Paralysis
• Viewgraph Engineering
• Death By Planning
• Fear of Success
• Corncob
• Intellectual Violence
• Smoke and Mirrors

• Death March Projects
• Project Mismanagement
• Irrational Management
• The Feud
• Fire Drill
• E-mail Is Dangerous
• Throw It over the Wall

62
Death March Projects

• Yourdon has described the death march project as
  one with unreasonable commitments Yourdon 97.
  He defines any project with goals or resources
  that are scoped 50 percent outside of reasonable
  norms as a death march project. This means one or
  more of the following
• The schedule is 50 too short.
• The size of the staff is only half as large as
  necessary.
• The budget is 50 too small.
• The number of features is 50 greater than
  comparable successful projects.
• Yourdon asserts that the root cause of death
  march projects is that "people are idiots."
• The more people involved in a product's
  development, the more complexity this adds to the
  task of error identification process, role,
  software defects, etc.) and error rectification.

63
Analysis Paralysis

• AntiPattern Name Analysis Paralysis
• Refactored Solution Name Iterative-Incremental
  Development
• Root Causes Pride, Narrow-Mindedness
• Unbalanced Forces Management of Complexity
• Anecdotal Evidence
• "We need to redo this analysis to make it more
  object-oriented, and use much more inheritance to
  get lots of reuse."
• "We need to complete object-oriented analysis,
  and design before we can begin any coding."
• "Well, what if the user wants to create the
  employee list based on the fourth and fifth
  letters of their first name combined with the
  project they charged the most hours to between
  Thanksgiving and Memorial Day of the preceding
  four years?"
• "If you treat each object attribute as an object,
  you can reuse field formatting between unrelated
  classes."

64
Analysis Paralysis

• AntiPattern Name Analysis Paralysis
• CommentAnalysis Paralysis occurs when the goal
  is to achieve perfection and completeness of the
  analysis phase. This AntiPattern is characterized
  by turnover, revision of the models, and the
  generation of detailed models that are less than
  useful to downstream processes.
• Symptoms And Consequences
• There are multiple project restarts and much
  model rework, due to personnel changes or changes
  in project direction.
• Design and implementation issues are continually
  reintroduced in the analysis phase.
• Cost of analysis exceeds expectation without a
  predictable end point.
• The analysis phase no longer involves user
  interaction. Much of the analysis performed is
  speculative.
• The complexity of the analysis models results in
  intricate implementations, making the system
  difficult to develop, document, and test.

65
Analysis Paralysis

• AntiPattern Name Analysis Paralysis
• Typical Causes
• The management process assumes a waterfall
  progression of phases. In reality, virtually all
  systems are built incrementally even if not
  acknowledged in the formal process.
• Management has more confidence in their ability
  to analyze and decompose the problem than to
  design and implement.
• Management insists on completing all analysis
  before the design phase begins.
• Goals in the analysis phase are not well defined.
• Planning or leadership lapses when moving past
  the analysis phase.
• Management is unwilling to make firm decisions
  about when parts of the domain are sufficiently
  described.
• The project vision and focus on the
  goal/deliverable to customer is diffused.
  Analysis goes beyond providing meaningful value.

66
Death By Planning

• AntiPattern Name Death by Planning
• Refactored Solution Name Rational Planning
• Root Causes Avarice, Ignorance, Haste
• Unbalanced Forces Management of Complexity
• Anecdotal Evidence
• "We can't get started until we have a complete
  program plan.
• "The plan is the only thing that will ensure our
  success."
• "As long as we follow the plan and don't diverge
  from it, we will be successful."
• "We have a plan we just need to follow it!
• BackgroundIn many organizational cultures,
  detailed planning is an assumed activity for any
  project. Death by Planning occurs when detailed
  plans for software projects are taken too
  seriously.

67
Death By Planning

• AntiPattern Name Death by Planning
• General FormMany projects fail from over
  planning. Over planning often occurs as a result
  of cost tracking and staff utilization
  monitoring. The two types of over planning are
  known
• (over) planning ceases once the project starts.
  Glass Case Plan
• over planning continues until the project ceases
  to exist, for a variety of unfulfilling reasons.
  Detailitis Plan

68
Death By Planning

• AntiPattern Name Death by Planning
• Glass Case PlanOften a plan is produced at the
  start of a project and never updated but always
  referenced as if it is an accurate current view
  of the project. This is fairly common as it gives
  the management a comfortable view of delivery,
  often before the project starts.
• Symptoms And Consequences
• The symptoms usually include at least one of the
  following
• Inability to plan at a pragmatic level.
• Focus on costs rather than delivery.
• Enough greed to commit to any detail as long as
  the project is funded.

69
Death By Planning

• AntiPattern Name Death by Planning
• Glass Case Plan
• Symptoms And Consequences
• The consequences are incremental
• Ignorance of the status of the project's
  development. The plan has no meaning, and control
  of delivery lessens as time goes on. The project
  may be well ahead or behind the intended
  deliverable state and no one would know.
• Failure to deliver a critical deliverable (the
  final consequence).
• Consequences grow incrementally until finally the
  project overruns, with the usual options of
• Further investment.
• Crisis project management.
• Cancellation.
• Possible loss of key staff.

70
Death By Planning

• AntiPattern Name Death by Planning
• Detailitis Plan
• Symptoms And Consequences
• The symptoms are a superset of the Glass Case
  Plan
• Inability to plan at a pragmatic level.
• Focus on costs rather than delivery.
• Spending more time planning, detailing progress,
  and replanning than on delivering software
• Project manager plans the project's activities.
• Team leaders plan the team's activities and the
  developers' activities.
• Project developers break down their activities
  into tasks.

71
Death By Planning

• AntiPattern Name Death by Planning
• Detailitis Plan
• Symptoms And Consequences
• The consequences are intertwined and feed off
  each other
• Each planner has to monitor and capture progress
  at the level shown by his or her plan, and
  re-estimate.
• Endless planning and replanning causes further
  planning and replanning.
• The objective shifts from delivery of software to
  delivery of a set of plans. Management assumes
  that because effort and cost are tracked,
  progress must be equivalent. In fact, there is no
  direct correlation.
• Continual delays to software delivery and
  eventual project failure.

72
Death By Planning

• AntiPattern Name Death by Planning
• Typical Causes
• In both cases, Glass Case Plan and Detailitis
  Plan the primary cause is lack of a pragmatic,
  common-sense approach to planning, schedules, and
  capture of progress.
• Refactored Solution
• The solution is the same for the Glass Case Plan
  and Detailitis Plan. A project plan should
  primarily show deliverables (regardless of how
  many teams are working on the project).
  Deliverables should be identified at two levels
• Product(s) defined as those artifacts that are
  sold to a customer, which includes the internal
  corporate lines of business that use them also.
• Components (within products) basic technology
  artifacts required to support a business service.
• The plan should be supplemented with validation
  gates for each component as well as the overall
  product.

73
Irrational Management

• AntiPattern Name Irrational Management
• Also Known As Pathological Supervisor,
  Short-Term Thinking, Managing by Reaction,
  Decision Phobia, Managers Playing with Technical
  Toys
• Refactored Solution Name Rational Decision
  Making
• Root Causes Responsibility (the universal cause)
• Unbalanced Forces Management of Resources
• Anecdotal Evidence
• "Who's running this project?"
• "I wish he'd make up his bloody mind!"
• "What do we do now?
• "We better clear this with management before we
  get started.
• "Don't bother asking they'll just say no.

74
Irrational Management

• AntiPattern Name Irrational Management
• Background
• Irrational Management covers a range of commonly
  occurring software project problems that can be
  traced back to the personalities of the person(s)
  running the project.
• For example, the manager may have obsessive
  interests in some aspect of the technology or
  personality limitations that cause them to become
  ineffective or irrational managers.
• Irrational management can be viewed as a skewed
  set of priorities where the manager's personal
  priorities, no matter how non-sensible, guide the
  software project in irrational directions.

75
Irrational Management

• AntiPattern Name Irrational Management
• General Form
• The manager (or management team) of one or more
  development projects cannot make decisions. This
  may be a personality defect or the result of an
  obsession with details.
• The details may be personal interests or
  behaviors of the manager, such as technical
  "toys" or micromanagement. When faced with a
  crisis, the manager's decisions are knee-jerk
  reactions rather than carefully thought-out
  strategies or tactical actions. These reactions
  often cause further problems. The cycle of
  indecision and reaction can escalate in frequency
  and severity of consequences.
• The Irrational Management AntiPattern is
  significantly compounded by a manager's inability
  to direct development staff. This is also called
  a lack of good people-management skills.

76
Smoke and Mirrors

• Also called Vaporware
• Demonstration systems are important sales tools,
  as they are often interpreted by end users as
  representational of production-quality
  capabilities. A management team, eager for new
  business, sometimes (inadvertently) encourage
  these misperceptions and makes commitments beyond
  the capabilities of the organization to deliver
  operational technology.
• End-users mistakenly assume that a brittle
  demonstration is a capability that is ready for
  operational use.
• Practice of proper ethics is important to manage
  expectations, risk, liabilities, and consequences
  in computing sales and marketing situations.
• Managing expectations often means it is better to
  let people expect less than can be delivered.
  When the expectations are exceeded, the
  recipients are pleasantly surprised, and are
  likely to become repeat customers.

77
Project Mismanagement

• AntiPattern Name Project Mismanagement
• Also Known As Humpty Dumpty
• Refactored Solution Name Risk Management
• Root Causes Responsibility (the universal cause)
• Unbalanced Forces Management of Risk (the
  universal force)
• Anecdotal Evidence
• "What went wrong? Everything was fine and then
  suddenly... KABOOM!

78
Project Mismanagement

• AntiPattern Name Project Mismanagement
• Background
• This AntiPattern concerns the monitoring and
  controlling of software projects.
• Project mismanagement involves mistakes made in
  the day to day running of a project, assuming
  planning errors (such as Death By Planning) have
  not been made.
• General Form
• Key activities are overlooked or minimized.
• These include technical planning (architecture)
  and quality-control activities (inspection and
  test). In particular, basic mistakes include
  inadequate architecture definition, insufficient
  code review (software inspection), and inadequate
  test coverage.

79
Project Mismanagement

• AntiPattern Name Project Mismanagement
• Symptoms And Consequences
• The design is difficult to implement due to lack
  of an architectural strategy.
• Code reviews and inspections happen infrequently
  and add minimal value.
• The test design requires extra effort and
  guesswork because the behavioral guidelines for
  the system are inadequately defined.
• In the integration and system testing phases,
  there is much project "thrashing" due to a large
  number of defects that should have been
  eliminated in earlier phases such as
  architecture, design, inspection, and unit
  testing.
• Defect reports escalate toward the end of the
  development and delivery/acceptance phases.

80
Project Mismanagement

• AntiPattern Name Project Mismanagement
• Typical Causes
• An inadequate architecture does not define the
  technical criteria for inspection, testing,
  integration, and interoperability.
• Code reviews and software inspections do not
  evaluate design defects, which then must be
  addressed in more expensive phases such as
  acceptance testing.
• Insufficient test suites check basic integration
  needs, but do not address full interoperability
  needs for the application.
• All of the preceding factors indicate ineffective
  risk management, which can be traced to the
  professional practices of the architect,
  designers, and management.
• Refactored Solution
• Proper risk management is an effective means of
  resolving predictable symptoms and consequences
  of the Project Mismanagement AntiPattern.

81
The Feud

• AntiPattern Name The Feud
• Also known as Dueling Corncobs, Territorial
  Managers, and Turf Wars,
• Context
• the Feud is marked by personality conflicts
  between managers that can dramatically affect the
  work environment.
• Forces
• Responsibility
• Root Causes
• Narrow-Mindedness
• Pride
• Ego

82
The Feud

• AntiPattern Name The Feud
• Symptoms
• Conflict erupts into ballistic verbal exchanges,
  verbal assassinations are carried out against
  staff to senior management.
• E-mail confrontations can greatly exacerbate the
  conflict (see the E-mail Is Dangerous
  mini-AntiPattern). Management feuds can drag on
  for years, with chronic recurrences of open
  hostilities, if not addressed promptly.

83
The Feud

• AntiPattern Name The Feud
• Consequences
• The employees reporting to these managers often
  suffer the consequences of their disagreements,
  because animosity between managers is generally
  reflected in the attitudes and actions of their
  employees, which always become negative.
• Consequently, software developers suffer from a
  lack of productive communications, and a general
  lack of cooperation inhibits any form of useful
  technology transfer. Thereafter, the corporate
  productivity and image can be negatively
  impacted.
• Loss of key personnel either by forced transfer
  or by resignation

84
E-mail Is Dangerous

• AntiPattern Name E-mail Is Dangerous
• Problem E-mail is an important communication
  medium for software developers. Unfortunately, it
  is an inappropriate medium for many topics and
  sensitive communications.
• Root Causes
• People are idiots. Failure to consider the
  consequences.
• General Form
• Symptoms and Consequences
• E-mail is inappropriate for most confrontational
  discussions. Tempers flair and feelings get hurt
  easily in e-mail debates.
• Worse, e-mail makes a public event out of the
  disagreement.
• Productivity and morale of a software project
  can quickly degenerate when other staff members
  get caught up in lengthy e-mail confrontations.

85
E-mail Is Dangerous

• AntiPattern Name E-mail Is Dangerous
• Symptoms and Consequences
• A "confidential" message is likely to end up in
  the inbox of the person you least want to read
  it. The best advice is to treat every e-mail as
  if it were going directly to your worst enemies
  and toughest competitors.
• E-mail can be distributed to large numbers of
  people instantaneously for example, to entire
  departments, companies, customer mailing lists,
  and public Internet forums.
• Treat every e-mail as if it will be printed on
  the front page of The Washington Post.
• An e-mail message can become a permanent written
  record. Treat every e-mail as if it could be used
  as evidence in a court of law.

86
E-mail Is Dangerous

• AntiPattern Name E-mail Is Dangerous
• Refactored Solution
• Use e-mail cautiously, as suggested.
• Avoid using e-mail for the following types of
  messages confrontations, criticisms, sensitive
  information, politically incorrect topics, and
  legally actionable statements.
• Use other media if there is any doubt about the
  appropriateness of e-mail.
• Although telephone conversations, fax
  transmissions, and face-to-face discussions are
  also vulnerable to disclosure, their potential
  for damage is much less imminent.

87
Summary AntiPatterns

• Blowhard JamboreeIndustry pundits disseminate
  marketing information that concerns
  consumers.In-house expertise is needed to
  separate the facts from the impressions.
• CorncobFrequently, difficult people obstruct and
  divert the software development
  process. Address agendas of the individual
  through various tactical, operational, and
  strategic organizational actions.

88
Summary AntiPatterns

• Viewgraph EngineeringOrganizations with limited
  technical capabilities for system development are
  taken at face value because they produce
  substantive documents and polished
  briefings. Verify the development capabilities
  of the organization and key project staff.
  Utilize prototyping and mockups as part of any
  system development process.
• Fear of SuccessPeople (software developers
  included) do crazy things when a project is near
  successful completion. When project completion
  is close-at-hand, a clear declaration of success
  is important for the project environment.

89
Summary AntiPatterns

• Intellectual ViolenceIntellectual violence
  occurs when someone who understands a theory,
  technology, or buzzword uses this knowledge to
  intimidate others in a meeting situation.
• Fire DrillAirline pilots describe flying as
  hours of boredom followed by 15 seconds of sheer
  terror. Many software projects resemble this
  situation Months of boredom followed by demands
  for immediate delivery. The months of boredom
  may include protracted requirements analysis,
  replanning, waiting for funding, waiting for
  approval, or any number of technopolitical
  reasons.

90
Summary AntiPatterns

• Throw It over the WallDocuments are produced and
  disseminated without any provision for technology
  transfer. Flexible guidelines are mistakenly
  interpreted as de facto policies or formal
  processes. Provision for the delivery and
  dissemination of information is essential to the
  planned implementation of any new processes or
  guidelines. Practices include instructional
  development, training delivery, and technology
  transfer kits.

91
Summary

• The purpose of project management AntiPatterns is
  to build new awareness that enables you to
  enhance your success.
• Management AntiPatterns describe how software
  projects are impaired by people issues,
  processes, resources, and external relationships.
  
• The patterns also describe some of the most
  effective solutions to these problems.

92
Next Class

• Topic Managing the Project Team
• Project environments cultural and social,
  international and political, physical
• Managing the Project Team
• Shaping project culture
• Reading
• PMP Study Guide Chapter 8
• Sommerville, Chapter 25
• Weinberg, Gerald M.,  The Psychology of Computer
  Programming Silver Anniversary Edition, ISBN
  0-932633-42-0
• Assignment 5 due.

93
Journal Exercises

• Thoughts on Scrum
• Have you experienced Scrum on a project? If so,
  how did it go?
• Thoughts on AntiPatterns