SE 477 Software and Systems Project Management - PowerPoint PPT Presentation

1 / 93
About This Presentation

SE 477 Software and Systems Project Management


Software and Systems Project Management Dennis Mumaugh, Instructor Office: CDM, Room 429 Office Hours: Tuesday, 4:00 5:30 – PowerPoint PPT presentation

Number of Views:614
Avg rating:3.0/5.0
Slides: 94
Provided by: Denni217


Transcript and Presenter's Notes

Title: SE 477 Software and Systems Project Management

SE 477 Software and Systems Project Management
  • Dennis Mumaugh, Instructor
  • Office CDM, Room 429
  • Office Hours Tuesday, 400 530

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

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
  • 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

SE 477 Class 9
  • Topics
  • Miscellaneous
  • Agile Project management
  • Project management anti-patterns

Thought for the day
  • The only way to get bad decisions is to make all
    of them yourself.

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

Agile DevelopmentAgile Project Management
  • ScrumReferenceCard/http//ScrumReferenceCard.comS
  • Pernicious Scrum Anti-Patterns http//www.drdobbs.

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.

  • 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

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
  • A working product is demonstrated to
  • 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.

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

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.

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

  • 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.

  • 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
  • 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

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

  • 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

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

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.

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.

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
  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
  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.

Agile Project Events
  • Project planning The initial planning for your
  • 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
  • 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.

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

  • 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
  • Scrum produces an executable, potentially
    shippable product increment at the end of each
  • 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

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
  • At the end of each sprint is the sprint

  • 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.

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

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
  • At the end, these features are done, meaning
    coded, tested and integrated into the evolving
    product or system.

  • 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

  • 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
  • share what they worked on the prior day,
  • The team runs through what it will do in the next
  • 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

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
  • 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.

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

Agile Project Management
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.

  • 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

How are Agile Projects Managed?
  • On a Scrum project, there are three roles
  • Product Owner
  • Team
  • Scrum Master

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
  • Responsible for product vision
  • Constantly re-prioritizes the Product Backlog,
    adjusting any long-term expectations such as
    release plans
  • Final arbiter of requirements questions

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

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

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

The Scrum Master
  • Facilitates the Scrum process
  • Helps resolve impediments
  • Creates an environment conducive to team
  • Captures empirical data to adjust forecasts
  • Shields the team from external interference and
    distractions to keep it in group flow (a.k.a. the
  • 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

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
  • 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.

  • 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

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
  • Other traditional tasks are distributed as well

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
  • 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.

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.

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

  • Anti-patterns
  • AntiPatterns, Brown, William J., John Wiley and
    Sons, 1998, ISBN 0-471-19713-0, see especially
    chapter 7
  • Project Management AntiPatterns
  • 5 Common Antipatterns in Software Project

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
  • 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
  • Patterns are formalized best practices that the
    programmer can use to solve common problems when
    designing an application or system.

What is an AntiPattern
  • Anti-patterns are certain patterns in software
    development that is considered a bad programming
  • 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.

Patterns vs. AntiPatterns
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

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

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

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

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
  • 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

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

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
  • 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.

Analysis Paralysis
  • AntiPattern Name Analysis Paralysis
  • Refactored Solution Name Iterative-Incremental
  • 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

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
  • The complexity of the analysis models results in
    intricate implementations, making the system
    difficult to develop, document, and test.

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
  • The project vision and focus on the
    goal/deliverable to customer is diffused.
    Analysis goes beyond providing meaningful value.

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
  • "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

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
  • (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

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
  • 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.

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.

Death By Planning
  • AntiPattern Name Death by Planning
  • Detailitis Plan
  • Symptoms And Consequences
  • The symptoms are a superset of the Glass Case
  • 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.

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
  • 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.

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

Irrational Management
  • AntiPattern Name Irrational Management
  • Also Known As Pathological Supervisor,
    Short-Term Thinking, Managing by Reaction,
    Decision Phobia, Managers Playing with Technical
  • Refactored Solution Name Rational Decision
  • 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.

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.

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.

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.

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!

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.

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
  • Defect reports escalate toward the end of the
    development and delivery/acceptance phases.

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.

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

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.

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
  • Loss of key personnel either by forced transfer
    or by resignation

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
  • 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
  • Productivity and morale of a software project
    can quickly degenerate when other staff members
    get caught up in lengthy e-mail confrontations.

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.

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.

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.

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.

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

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.

  • 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.

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
  • Assignment 5 due.

Journal Exercises
  • Thoughts on Scrum
  • Have you experienced Scrum on a project? If so,
    how did it go?
  • Thoughts on AntiPatterns
Write a Comment
User Comments (0)