True Confessions of a Project Manager

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