Your SlideShare is downloading. ×
0
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
True Confessions of a Project Manager
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

True Confessions of a Project Manager

303

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
303
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. True Confessions of a Project Manager CFICSE Sandy Smith October 16, 2002
  • 2. Agenda Introduction Disclaimer The Project The Approach Employed The Results Questions & Discussion
  • 3. Introduction 10+ years experience in software development Began in development and moved into management Public & Private Sectors Projects Large Commercial GIS Air Traffic Control “Fast-time” Simulator Operations Management System eCommerce applications
  • 4. Disclaimer Case study only Accounting of What Occurred Review of the Results The presentation reflects the actions of an actual project team but names have been changed to protect the innocent
  • 5. The Company Small software company owned by a large manufacturing firm Specializing in eCommerce applications Small Development Team Focus on Maintenance No formal Standards or Processes
  • 6. The Project eCommerce software dated No documentation Lack of Structure in Application Increasing Maintenance Costs Requirement for Addition of Major Functionality Add-on to existing or re-design product? Build versus Buy?
  • 7. Project Constraints Resources No formal project budget Lack of specific commitment from parent Performance Requirements unclear Client contact limited Time To be completed within 8 months
  • 8. Resources No formal budget process Operating on a cash flow basis Recognition of expenditure requirements Limited recruitment to build the development team Minimal training budget Minimal use of external resources Acquisition of tools
  • 9. Performance Baseline was the existing product Requirement gathering very unstructured Limited contact with actual customer Fact-finding a challenge Ultimate Project Goal Develop a product that could be enhanced rapidly and with minimal cost
  • 10. Time Extremely constrained (8 months) Not unusual for internet-based applications Typical project cycles <= 3 months Planning in hours not days Impacted on… Tools selected given the learning curve Recruitment and training of new staff Use of formal processes
  • 11. Approach Employed Pragmatic Controls could not Impede Progress Staff Comfortable with Methodology Rapid Development Cycle Low cost
  • 12. Finding a Methodology Go to the forum you are developing for Internet as a research forum On-line Articles Followed up on references Discussions Staff input
  • 13. Formal vs.. Radical Process Formal Structured Process-oriented Proactive Control Radical Open Goal-oriented Reactive Leap of Faith
  • 14. Extreme Programming Elements of this process were critical Pair-programming used as a training tool Building incrementally Testing continually Complete methodology not realistic for our culture Radical change to individual work processes Resistance to “interference”
  • 15. Unified Modeling Language Mechanism to document development Use cases Simple syntax for users to review Minimize documentation but maximize content Integration with modeling tool (TogetherJ) Linkage between documents Outcome → Automatic Code Generation
  • 16. The Framework Manage Software Development within a Chaotic Environment (Controlled Chaos) “Call a team meeting and tell them that they have been selected to do an important project. Describe the project, include how long it’s estimated to take, how much it is estimated to cost, how it is expected to perform, etc. Tell them that their job is to do it in half the time, with half the cost, twice the performance, etc.”
  • 17. Scrum What follows is the actual material that was presented to the development team in outlining how the process would work for our project…
  • 18. Scrum - Why Use It? A process for managing development... When requirements are rapidly changing This is true for us in that we will have to re- scope our use cases (the requirements) as we progress to meet our timelines We will also be asked to extend our scope at times
  • 19. Scrum - Why Use It? When there is a need to control conflicting interests and opinions and not get bogged down in project politics Balance the needs of ‘the parent’ with the needs of one of their major clients
  • 20. Scrum - Why Use It? When the project team needs a mechanism to detect and remove anything that gets in the way of developing and delivering products
  • 21. Scrum - Why Use It? When there is a need to maximize productivity Timelines are tight and we must ensure everyone can be as productive as possible Productivity ≠ 12 hour days but means that for each hour of work in a day you realize the maximum results from that hour
  • 22. Some Philosophy It is critical that everyone to feel good about their job, their contributions, and that they have done the very best they possibly could You need to have a good mental relationship with your work and that comes from satisfaction with what you accomplish each day
  • 23. Scrum In Detail It is a radically different approach to software development It empowers the project team by creating a structure in which Performance is optimized Progress of work is monitored The progress is used to adapt expectations based on what is or can be accomplished
  • 24. Scrum In Detail The name comes from a team pack in Rugby, everybody in the pack acts together with everyone else to move the ball down the field
  • 25. What Scrum is Not It will not spell out in intricate details how to accomplish a task, test a product or document the results Scrum is just a framework in which these specific processes exist Bring in processes from other software development methodologies, e.g., Unified Process, Extreme Programming, Waterfall, IEEE, DoD-Std 2167A
  • 26. What Scrum is Not It is not a way for “management”to extract the maximum amount of work out of you This is a way for us to determine what is possible and to make the adjustments necessary to accomplish our goals A project manager is just a facilitator whose role is to ensure the project team is successful
  • 27. Scrum’s 3 Level Approach
  • 28. How Does It Work? Management sets a tentative release date for a set of features, facilities, and requirements to be in a product The development Scrum then iteratively produces the best product possible within that time frame
  • 29. How Does It Work? As development occurs, the PM assesses progress and adjusts the following four variables accordingly : Time : when will the release be available? Functionality : what will the release contain? Quality : what is good enough quality for this type of product? Cost : how much resource will be used to build the product?
  • 30. Remember The parameters are adjusted to get the best product possible to market within the acceptable timeframe
  • 31. Chickens & Pigs A chicken and a pig are together when the chicken says, "Let's start a restaurant!". The pig thinks it over and says, "What would we call this restaurant?". The chicken says, "Ham n' Eggs!". The pig says, "No thanks, I'd be committed, but you'd only be involved!".
  • 32. Where do we go from here? Create the Team… People who do the work are the pigs, those that have an interest (but are not doing work) are the chickens Teams should be 4 to 7 people and are called a Scrum Multiple Scrums can exist where each Scrum focuses on one, self-contained area of work
  • 33. Where do we go from here? Appoint a Scrum Master This is the PM and they are responsible for the care and well-being of the Scrum Team, as well as… Daily Scrum meetings Measuring progress, making decisions and clearing all impediments out of the way of the team Keeping the “chickens” quiet
  • 34. Where do we go from here? Establish and conduct daily Scrum meetings This is a daily meeting held at the same time and place It is is a status check where the team meets and updates each other about what's going on It provides a daily focus on the work being done
  • 35. Rules for the Scrum Meetings Starts at the same time and place daily Chickens are invited to listen, but not to talk or ask questions No more than 30 minutes (most meetings are 10-15 minutes)
  • 36. Rules for the Scrum Meetings Starting to the Scrum Master's left, the Scrum Master has all pigs answer : What did you do since last Scrum? What got in your way of doing work? What will you do before the next Scrum?
  • 37. Rules for the Scrum Meetings Scrum Master is responsible for making decisions that the team can't make on its own (these need to be raised in these meetings) Scrum master is responsible for noting and resolving work impediments All discussions other than replies to the 3 key questions are deferred to later meetings
  • 38. Objectives of the Scrum Every day the team synchronizes and finds ways to help each other Eliminates most communication, status, reporting meetings Creates a team atmosphere and spirit Builds knowledge and quickly applies knowledge
  • 39. Benefits of the Scrum Let's management know daily what it can do to increase probability of product success Highlights roadblocks and impediments, particularly if the same one's are being reported over and over
  • 40. Benefits of the Scrum Makes development acceleration visible Makes everything regarding the product development visible Someone is responsible for immediately making decisions and removing impediments
  • 41. Product Planning Products are developed through sub- cycles or Sprints Sprints last approximately 30 days Each Sprint is broken into 1 day iterations that conclude with the daily Scrum Meeting At the end of each daily cycle - prior to the daily Scrum meeting - a product build is completed The build helps in determining whether status is accurate
  • 42. The Sprint The Sprint is a closed operation - impervious to outside changes - where the team gets to build the best software that they can in the time given During the Sprint the team must be isolated from all outside interference
  • 43. The Backlog What is developed during the Sprint is determined by the prioritized list of work referred to as the “Product Backlog” The team selects a cohesive group of top priority backlog, that – once completed – will have reached an objective, or milestone This becomes the Sprint Goal or Objective
  • 44. The Sprint Backlog The team decomposes the backlog into tasks which form the Sprint Backlog These tasks are discrete pieces of work that various team members sign up to do During the Sprint, the team can add, modify, or remove Sprint backlog as they decide appropriate ... to meet the goal that they signed up for
  • 45. Sprint Progress The team must determine the best way to develop the product functionality that is included in the Sprint The daily Scrum Meeting is the way to communicate status and share knowledge This is the forum to provide the Scrum Master with direct visibility into the project --- warts and all
  • 46. Sprint Lifecycle
  • 47. To Make this Work You need a few things in place… Good Engineering Practices Experienced Software Developers Management Who Can Let Go The Right Culture A Lot of Trust and Honesty
  • 48. What Went Wrong? Bad management No process, however good, can compensate for bad management practices Requirements Vacillating requirements can quickly kill any development initiative Ability to track requirements and changes to requirements is a MUST
  • 49. What Went Wrong? Experience of Staff An inexperienced team will be challenged in dealing with a Sprint Developers have a difficult time in being able to sacrifice quality to meet timelines View of Progress A view of actual progress is difficult even with a daily build
  • 50. What Would I do Differently? Nothing There is no methodology or process that can save a project that is doomed Process and methodology do not guarantee you management commitment, consistent funding or a stable business environment What they actually do is just help you to cope with the situation more effectively

×