Post on 17-Jan-2015
description
True Confessions of a Project Manager
CFICSESandy SmithOctober 16, 2002
Agenda
IntroductionDisclaimerThe ProjectThe Approach Employed The ResultsQuestions & Discussion
Introduction
10+ years experience in software development
Began in development and moved into management
Public & Private SectorsProjects
Large Commercial GISAir Traffic Control “Fast-time” SimulatorOperations Management SystemeCommerce applications
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
The Company
Small software company owned by a large manufacturing firmSpecializing in eCommerce applicationsSmall Development TeamFocus on Maintenance No formal Standards or Processes
The Project
eCommerce software dated No documentationLack of Structure in ApplicationIncreasing Maintenance Costs
Requirement for Addition of Major Functionality
Add-on to existing or re-design product?Build versus Buy?
Project Constraints
Resources No formal project budgetLack of specific commitment from parent
PerformanceRequirements unclearClient contact limited
TimeTo be completed within 8 months
Resources
No formal budget processOperating on a cash flow basisRecognition of expenditure requirements
Limited recruitment to build the development teamMinimal training budgetMinimal use of external resourcesAcquisition of tools
Performance
Baseline was the existing productRequirement gathering very unstructured
Limited contact with actual customerFact-finding a challenge
Ultimate Project Goal Develop a product that could be enhanced rapidly and with minimal cost
Time
Extremely constrained (8 months)Not unusual for internet-based applicationsTypical project cycles <= 3 monthsPlanning in hours not days
Impacted on…Tools selected given the learning curveRecruitment and training of new staffUse of formal processes
Approach Employed
PragmaticControls could not Impede ProgressStaff Comfortable with MethodologyRapid Development CycleLow cost
Finding a Methodology
Go to the forum you are developing for
Internet as a research forumOn-line Articles
Followed up on references
Discussions
Staff input
Formal vs.. Radical Process
FormalStructuredProcess-orientedProactiveControl
RadicalOpenGoal-orientedReactiveLeap of Faith
Extreme Programming
Elements of this process were criticalPair-programming used as a training toolBuilding incrementallyTesting continually
Complete methodology not realistic for our culture
Radical change to individual work processesResistance to “interference”
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 documentsOutcome Automatic Code Generation
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.”
Scrum
What follows is the actual material that was presented to the development team in outlining how the process would work for our project…
Scrum - Why Use It?
A process for managing development...
When requirements are rapidly
changingThis is true for us in that we will have to re-scope our use cases (the requirements) as we progress to meet our timelinesWe will also be asked to extend our scope at times
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
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
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 possibleProductivity 12 hour days but means that for each hour of work in a day you realize the maximum results from that hour
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 couldYou need to have a good mental relationship with your work and that comes from satisfaction with what you accomplish each day
Scrum In Detail
It is a radically different approach to software developmentIt 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
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
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 existBring in processes from other software development methodologies, e.g., Unified Process, Extreme Programming, Waterfall, IEEE, DoD-Std 2167A
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 goalsA project manager is just a facilitator whose role is to ensure the project team is successful
Scrum’s 3 Level Approach
How Does It Work?
Management sets a tentative release date for a set of features, facilities, and requirements to be in a productThe development Scrum then iteratively produces the best product possible within that time frame
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?
Remember
The parameters are adjusted to get the best product possible to market within the acceptable timeframe
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!".
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 chickensTeams should be 4 to 7 people and are called a ScrumMultiple Scrums can exist where each Scrum focuses on one, self-contained area of work
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 meetingsMeasuring progress, making decisions and clearing all impediments out of the way of the teamKeeping the “chickens” quiet
Where do we go from here?
Establish and conduct daily Scrum meetings
This is a daily meeting held at the same time and placeIt is is a status check where the team meets and updates each other about what's going onIt provides a daily focus on the work being done
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)
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?
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
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 spiritBuilds knowledge and quickly applies knowledge
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
Benefits of the Scrum
Makes development acceleration visible Makes everything regarding the product development visibleSomeone is responsible for immediately making decisions and removing impediments
Product Planning
Products are developed through sub-cycles or Sprints
Sprints last approximately 30 daysEach Sprint is broken into 1 day iterations that conclude with the daily Scrum MeetingAt the end of each daily cycle - prior to the daily Scrum meeting - a product build is completedThe build helps in determining whether status is accurate
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 givenDuring the Sprint the team must be isolated from all outside interference
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 milestoneThis becomes the Sprint Goal or Objective
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
Sprint Progress
The team must determine the best way to develop the product functionality that is included in the SprintThe 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
Sprint Lifecycle
To Make this Work
You need a few things in place…Good Engineering PracticesExperienced Software Developers Management Who Can Let GoThe Right CultureA Lot of Trust and Honesty
What Went Wrong?
Bad managementNo process, however good, can compensate for bad management practices
RequirementsVacillating requirements can quickly kill any development initiativeAbility to track requirements and changes to requirements is a MUST
What Went Wrong?
Experience of StaffAn inexperienced team will be challenged in dealing with a SprintDevelopers have a difficult time in being able to sacrifice quality to meet timelines
View of ProgressA view of actual progress is difficult even with a daily build
What Would I do Differently?
NothingThere is no methodology or process that can save a project that is doomedProcess and methodology do not guarantee you management commitment, consistent funding or a stable business environmentWhat they actually do is just help you to cope with the situation more effectively