Presentation is loading. Please wait.

Presentation is loading. Please wait.

SE 477 Software and Systems Project Management Dennis Mumaugh, Instructor Office: CDM, Room 432 Office Hours: Monday, 4:00 – 5:30.

Similar presentations


Presentation on theme: "SE 477 Software and Systems Project Management Dennis Mumaugh, Instructor Office: CDM, Room 432 Office Hours: Monday, 4:00 – 5:30."— Presentation transcript:

1 SE 477 Software and Systems Project Management Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 432 Office Hours: Monday, 4:00 – 5:30 May 25, 2015SE 477: Lecture 91 of 93

2 Administrivia  Comments and feedback  Lectures?  Work Load?  Reading?  Progress  Project  Journal May 25, 2015SE 477: Lecture 9 2 of 93

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 1.Loss of configuration files renders system unworkable 2.Loss of hardware (bad computer, bad drives) 3.Loss of source files (disk corruption) 4.Loss of network (see 1 above)  Loss of work (aka source code) and need to rewrite code 1.Backups essential 2.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.] May 25, 2015SE 477: Lecture 9 3 of 93

4 SE 477 – Class 9 Topics:  Miscellaneous: »Agile Project management »Project management anti-patterns; May 25, 2015SE 477: Lecture 9 4 of 93

5 Thought for the day The only way to get bad decisions is to make all of them yourself. May 25, 2015SE 477: Lecture 95 of 93

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 May 25, 2015SE 477: Lecture 9 6 of 93

7 Agile Development Agile Project Management May 25, 2015SE 477: Lecture 97 of 93

8 Readings  Scrum Primer (all) Scrum Primer  ScrumReferenceCard /http://ScrumReferenceCard.comScrumReferenceCard.pdf ScrumReferenceCard /http://ScrumReferenceCard.comScrumReferenceCard.pdf  Pernicious Scrum Anti-Patterns http://www.drdobbs.com/architecture-and-design/pernicious-scrum- anti-patterns/240168658 Pernicious Scrum Anti-Patterns http://www.drdobbs.com/architecture-and-design/pernicious-scrum- anti-patterns/240168658 May 25, 2015SE 477: Lecture 9 8 of 93

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. May 25, 2015SE 477: Lecture 9 9 of 93

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 May 25, 2015SE 477: Lecture 9 10 of 93

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. May 25, 2015SE 477: Lecture 9 11 of 93

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 May 25, 2015SE 477: Lecture 9 12 of 93

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. May 25, 2015SE 477: Lecture 9 13 of 93

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 May 25, 2015SE 477: Lecture 9 14 of 93

15 Scrum  Within agile development, Scrum has the most to say about exactly what is agile project management. So let’s use Scrum as our model for answering this question. May 25, 2015SE 477: Lecture 9 15 of 93

16 Scrum http://en.wikipedia.org/wiki/Image:Rugby_union_scrummage.jpg http://www.controlchaos.com May 25, 2015SE 477: Lecture 9 16 of 93

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 fo cus May 25, 2015SE 477: Lecture 9 17 of 93

18 Scrum Lifecycle  Planning  Vision, expectations, funding  Staging  Identify requirements, prioritize iteration  Development  Implement system ready for release in each sprint  Release  Operational deployment May 25, 2015SE 477: Lecture 9 18 of 93

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 May 25, 2015SE 477: Lecture 9 19 of 93

20 Scrum Values  Commitment  Team takes responsibility to complete the Sprint. To avoid things that will stand in its way  Focus  Team’s 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 May 25, 2015SE 477: Lecture 9 20 of 93

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. May 25, 2015SE 477: Lecture 9 21 of 93

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. May 25, 2015SE 477: Lecture 9 22 of 93

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. May 25, 2015SE 477: Lecture 9 23 of 93

24 Agile Project Events 1. 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. 2. Release planning: Planning the next set of product features to release 3. Sprint: A short cycle of development, in which the team creates potentially shippable product functionality. 4. Sprint planning: A meeting at the beginning of each sprint where the scrum team commits to a sprint goal. 5. 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. May 25, 2015SE 477: Lecture 9 24 of 93

25 Agile Project Events 6. Sprint review: A meeting at the end of each sprint, where the development team demonstrates the working product functionality it completed during the sprint. 7. 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. May 25, 2015SE 477: Lecture 9 25 of 93

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 defines 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 met–no “it’s 80% done” is allowed  This demonstrates value iteratively to the product owner and to other stakeholders May 25, 2015SE 477: Lecture 9 26 of 93

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. May 25, 2015SE 477: Lecture 9 27 of 93

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. May 25, 2015SE 477: Lecture 9 28 of 93

29 Scrum Meetings May 25, 2015SE 477: Lecture 9  Planning meeting  Sprint  Scrum meeting  Sprint review  Sprint retrospective 29 of 93

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. May 25, 2015SE 477: Lecture 9 30 of 93

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 May 25, 2015SE 477: Lecture 9 31 of 93

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 May 25, 2015SE 477: Lecture 9 32 of 93

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. May 25, 2015SE 477: Lecture 9 33 of 93

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. May 25, 2015SE 477: Lecture 9 34 of 93

35 Agile Project Management May 25, 2015SE 477: Lecture 935 of 93

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. May 25, 2015SE 477: Lecture 9 36 of 93

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? May 25, 2015SE 477: Lecture 9 37 of 93

38 How are Agile Projects Managed? May 25, 2015SE 477: Lecture 938 of 93

39 Scrum  On a Scrum project, there are three roles:  Product Owner  Team  Scrum Master May 25, 2015SE 477: Lecture 9 39 of 93

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 May 25, 2015SE 477: Lecture 9 40 of 93

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 May 25, 2015SE 477: Lecture 9 41 of 93

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 May 25, 2015SE 477: Lecture 9 42 of 93

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 May 25, 2015SE 477: Lecture 9 43 of 93

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 May 25, 2015SE 477: Lecture 9 44 of 93

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. May 25, 2015SE 477: Lecture 9 45 of 93

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. May 25, 2015SE 477: Lecture 9 46 of 93

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 May 25, 2015SE 477: Lecture 9 47 of 93

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. May 25, 2015SE 477: Lecture 9 48 of 93

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. May 25, 2015SE 477: Lecture 9 49 of 93

50 Thought for the day “We have met the enemy and he is us.” – Pogo May 25, 2015SE 477: Lecture 950 of 93

51 AntiPatterns May 25, 2015SE 477: Lecture 951 of 93

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-project-management- antipatterns Project Management AntiPatterns http://sourcemaking.com/antipatterns/software-project-management- antipatterns  5 Common Antipatterns in Software Project Management http://codebuild.blogspot.com/2012/06/5-common-antipatterns-in- software.html 5 Common Antipatterns in Software Project Management http://codebuild.blogspot.com/2012/06/5-common-antipatterns-in- software.html May 25, 2015SE 477: Lecture 9 52 of 93

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. May 25, 2015SE 477: Lecture 9 53 of 93

54 What is an AntiPattern  A nti-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. May 25, 2015SE 477: Lecture 9 54 of 93

55 Patterns vs. AntiPatterns May 25, 2015SE 477: Lecture 9 55 of 93

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] May 25, 2015SE 477: Lecture 9 56 of 93

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] May 25, 2015SE 477: Lecture 9 57 of 93

58 Root causes  Haste  Apathy  Narrow-Mindedness  Sloth  Avarice  Ignorance  Pride (NIH) May 25, 2015SE 477: Lecture 9 58 of 93

59 Primal Forces  Management of Functionality  Management of Performance  Management of Complexity  Management of Change  Management of IT resources  Management of Technology Transfer May 25, 2015SE 477: Lecture 9 59 of 93

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 a)forget half-way through that it is an anti-pattern, and start reading it as a positive pattern, b)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". May 25, 2015SE 477: Lecture 9 60 of 93

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 May 25, 2015SE 477: Lecture 9 61 of 93

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. May 25, 2015SE 477: Lecture 9 62 of 93

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." May 25, 2015SE 477: Lecture 9 63 of 93

64 Analysis Paralysis AntiPattern Name: Analysis Paralysis Comment: Analysis 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. May 25, 2015SE 477: Lecture 9 64 of 93

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. May 25, 2015SE 477: Lecture 9 65 of 93

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!” Background In 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. May 25, 2015SE 477: Lecture 9 66 of 93

67 Death By Planning AntiPattern Name: Death by Planning General Form: Many 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] May 25, 2015SE 477: Lecture 9 67 of 93

68 Death By Planning AntiPattern Name: Death by Planning Glass Case Plan: Often 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. May 25, 2015SE 477: Lecture 9 68 of 93

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. May 25, 2015SE 477: Lecture 9 69 of 93

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. May 25, 2015SE 477: Lecture 9 70 of 93

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. May 25, 2015SE 477: Lecture 9 71 of 93

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. May 25, 2015SE 477: Lecture 9 72 of 93

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. May 25, 2015SE 477: Lecture 9 73 of 93

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. May 25, 2015SE 477: Lecture 9 74 of 93

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. May 25, 2015SE 477: Lecture 9 75 of 93

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. May 25, 2015SE 477: Lecture 9 76 of 93

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!” May 25, 2015SE 477: Lecture 9 77 of 93

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. May 25, 2015SE 477: Lecture 9 78 of 93

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. May 25, 2015SE 477: Lecture 9 79 of 93

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. May 25, 2015SE 477: Lecture 9 80 of 93

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 May 25, 2015SE 477: Lecture 9 81 of 93

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. May 25, 2015SE 477: Lecture 9 82 of 93

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 resignati on May 25, 2015SE 477: Lecture 9 83 of 93

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. May 25, 2015SE 477: Lecture 9 84 of 93

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. May 25, 2015SE 477: Lecture 9 85 of 93

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. May 25, 2015SE 477: Lecture 9 86 of 93

87 Summary AntiPatterns  Blowhard Jamboree Industry pundits disseminate marketing information that concerns consumers. In-house expertise is needed to separate the facts from the impressions.  Corncob Frequently, difficult people obstruct and divert the software development process. Address agendas of the individual through various tactical, operational, and strategic organizational actions. May 25, 2015SE 477: Lecture 9 87 of 93

88 Summary AntiPatterns  Viewgraph Engineering Organizations 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 Success People (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. May 25, 2015SE 477: Lecture 9 88 of 93

89 Summary AntiPatterns  Intellectual Violence Intellectual violence occurs when someone who understands a theory, technology, or buzzword uses this knowledge to intimidate others in a meeting situation.  Fire Drill Airline 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. May 25, 2015SE 477: Lecture 9 89 of 93

90 Summary AntiPatterns  Throw It over the Wall Documents 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. May 25, 2015SE 477: Lecture 9 90 of 93

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. May 25, 2015SE 477: Lecture 9 91 of 93

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:  MBOK-SWE Ch. 2.3, Ch. 9  Sommerville, Chapter 25  Weinberg, Gerald M., The Psychology of Computer Programming: Silver Anniversary Edition, ISBN 0- 932633-42-0 Assignment 5 due. May 25, 2015SE 477: Lecture 9 92 of 93

93 Journal Exercises  Thoughts on Scrum  Have you experienced Scrum on a project? If so, how did it go?  Thoughts on AntiPatterns May 25, 2015SE 477: Lecture 9 93 of 93


Download ppt "SE 477 Software and Systems Project Management Dennis Mumaugh, Instructor Office: CDM, Room 432 Office Hours: Monday, 4:00 – 5:30."

Similar presentations


Ads by Google