SE 477 Software and Systems Project Management - PowerPoint PPT Presentation

Loading...

PPT – SE 477 Software and Systems Project Management PowerPoint presentation | free to view - id: 714a22-MThmO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

SE 477 Software and Systems Project Management

Description:

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

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

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com