Deliver Projects On Time, Every Time

TA Full‐day Tutorial 6/4/2013 8:30 AM

"Deliver Projects On Time, Every Time"

Presented by:

Ken Whitaker Leading Software Maniacs

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com

Ken Whitaker Leading Software Maniacs

Ken Whitaker of Leading Software Maniacs™ (LSM) has more than twenty-five years of software development executive leadership and training experience in a variety of technology roles and industries, leading many commercial software development teams. He is an active PMI® member, Project Management Professional certified, and a Certified ScrumMaster. Ken’s presentations come from case studies, personal leadership experience, the PMI Project Management Book of Knowledge (PMBOK® Guide), and his leadership books—Managing Software Maniacs, Principles of Software Development Leadership, and I’m Not God, I’m Just a Project Manager. Last year Ken introduced eLearning classes on pmuniversity.com and free, project management tutorials on pmchalkboard.com. Learn more at leadingswmaniacs.com.

Copyright © Leading Software Maniacs, LLC. All Rights Reserved.

Deliver Projects On Time, Every Time- AM 1


Ken Whitakerı

Deliver Projects On Time, Every Time!

(Applying PMBOK ® Guide to Agile Software Development)

Are You in the Right Class?

§  There appears to be a gap …




Are You in the Right Class?

§  This seminar is designed to bridge that gap



Ken Whitakerı


(Applying PMBOK ® Guide to Agile Software Development)



Background

Ken Whitaker, PMP, CSM §  Over 25 years of software leadership

experience §  Speaker at dozens of software industry events §  Creator of Software Success

“Delivery of On-time, Bug-Free Software” US/Canadian tour

§  Project Management Professional (PMP)® §  Certified ScrumMaster


Background

Ken Whitaker, PMP, CSM §  Author of Managing Software

Maniacs (J Wiley & Sons) §  Author of Principles of

Software Development Leadership (Course Technology PTR)




Drawing For a Free Book!

Leave your business card on the back table. One free copy of Managing Software Maniacs will be given away at the end of the class!


Drawing For a Free Book!

Leave your business card on the back table. One free copy of Managing Software Maniacs will be given away at the end of the class!




Legal Stuff …

Leading Software Maniac Marks

Applying Project Management Principles to Software Development Leadership, Principles of Software Development Leadership, 4Ps,

Leading Software Maniacs, Soft-Audit, jus’ e’nuff, Nerd Herd Game, the 4Ps logo, the Leading Software Maniacs logo, and the Nerd Herd Game

logo are marks of Leading Software Maniacs, LLC.

Project Management Institute Marks PMI, PMP, PMBOK, the PMI logo, and the PMI Registered Education Provider logo are registered marks of the Project Management Institute,

Inc.


One simple question…

16 Copyright © Leading Software Maniacs, LLC. All Rights Reserved.

What do you want to learn today?



Agenda

Morning §  Is a New Process Methodology Needed? §  Align to Your Company Vision §  Introduction to Agile Thinking §  Overview of the Agile Workflow §  What Have We Learned?


Agenda

Afternoon §  How the Scrum Workflow Really Works §  Define Project Scope the First Time §  Successfully Transition to an Agile Organization §  What Have We Learned?





Agenda


Is a New Process Methodology Needed?

Topics: §  Statistics You May Not Want to Know About §  The Importance of Process §  Is Waterfall All That Bad?





Disclaimer

This class is not a ScrumMaster Certification class!



Disclaimer

This class is not a ScrumMaster Certification class!


Sooo, if that’s what you thought—pack

your bags and GIT OUT!




Statistics You May Not Want to Know About §  Was your project successful?


CHAOS 2004 Resolution of Projects survey results (The Standish Group)

Failed18%

Challenged53%

Succeeded29%


Statistics You May Not Want to Know About §  Key impacts from project failure

1.  Restarts 2.  Cost overruns 3.  Time overruns


CHAOS 2000 survey results (The Standish Group)




Project Size People Time (in Months) Success Rate

< $750K 6 6 55%

$750K to $1.5M 12 9 33%

$1.5M 25 12 25%

> $10M 500 36 0%

Statistics You May Not Want to Know About §  Do large projects and large software companies

(with lots of resources) predict success?


CHAOS 2000 survey results (The Standish Group)


Statistics You May Not Want to Know About §  And, there’s more …

§  Requirements change about 25% of the time … talk about being set up for failure!





Statistics You May Not Want to Know About §  Over 50% of requested features aren’t even used


Jim Johnson, XP 2002 requested feature survey results (The Standish Group)

Always7%

Often13%

Sometimes16%

Rarely19%

Never45%

Could this be an

example of the 80/20

rule?


The Importance of Process §  PMI® provides guidance for process

management §  About 300,000 project managers belong to PMI §  Many are in the technology (software) world …

… and struggling with embracing agile concepts





The Importance of Process §  How many of you belong to PMI®? §  PMI has worldwide recognition §  How many of you that belong to PMI are

Project Management Professional (PMP)®

certified? §  The PMBOK ® Guide is the key reference of PMI

and for PMP® certification §  PMBOK ® Guide updated every four years

Copyright © Leading Software Maniacs, LLC . All Rights Reserved.


The Importance of Process §  Project Management

The application of knowledge, skills, tools, and techniques to project activities to meet project requirements

§  Project Management System The set of tools, techniques, methodologies, resources, and procedures used to manage a project





Two class types of projects §  Predictive §  Adaptive



Integration Scope Time Cost

Quality Human Resources

Communications Risk

Procurement

The Importance of Process §  Definitive guide for project best practices §  Divided into nine knowledge areas





Process Groups

Initiating Planning Executing Monitoring & Controlling

Closing

The Importance of Process §  Five distinct, sequenced process groups



Process Groups

Implementation


Closing

The Importance of Process §  Each knowledge area defines processes





Best Practice §  Every project manager and every software

manager should: §  Join PMI® §  Become Project Management Professional

(PMP)® certified



The Importance of Process §  A process should provide predictability

§  Repeatable set of steps § Guidance for the team (rules of engagement) §  Clear roles and responsibilities §  Produces results that deliver quality projects

on time





Famous Last Words §  A not-so-famous marketing consultant said

“Any software development team can get by

without a process once …

… but they’ll always get beaten by a competitor with a process in the long run.”



Is Waterfall All That Bad? §  A

logical, ordered set of steps


Requirements

Design

Detailed Design

Coding & Debugging

Testing & Documentation

Release

Time



Feature Description

Specifications Well-defined requirements and specifications

Schedules Laid out usually to a specific date (desired)

Sequence of Events One process after another (mostly)

Adaptable to Change Not at all, any change usually slips the schedule

Easy to Understand Yes, especially to non-technical stakeholders

Involve Customers Near the end of a project (or with a beta program)


Is Waterfall All That Bad? §  Highlights



Is Waterfall All That Bad? §  There’s

the impact of risk…


Risk

Impa

ct

Time

Waterfall

Waterfall projects encounter risks late in a project’s life cycle




Is Waterfall All That Bad? §  According to Steve McConnell’s Rapid

Development, there are waterfall variations §  Sashimi waterfall § Waterfall with subprojects

§  Also, jot down how much time you and your team dedicate to meetings per week on a typical project?



Is Waterfall All That Bad? §  According to Agile & Iterative Development, the

waterfall method has some real deficiencies 1.  Users aren’t always sure what they want …

… and once they see the work, they’ll want it changed

2.  Details usually come out during the work 3.  Forcing up-front specs are rarely accurate





Is Waterfall All That Bad? §  Final thoughts

§ Waterfall is a long series of consecutive steps … that appear disconnected

§ Handoffs are typically sloppy §  Success seems far, far away §  Integration and late testing introduce risk §  In practice, schedules are rarely predictable



Agenda




Align to Your Company Vision

Topics: §  Partner with Product Management §  Introducing the Decision Pyramid §  Clearly Define the Project Charter



Process Groups

Implementation

Initiating Planning Execution Monitoring & Controlling

Closing

Develop Project Charter

Develop Project Management Plan

Direct and Manage Project Execution

Monitor and Control Project Work

Close Project or Phase

…

Project Integration Management Knowledge Area §  How important is setting the vision at project

initiation?





Partner with Product Management §  Close collaboration required


The “Boss” (Customer)

Clear ownership of the Specification (the WHAT)

The Project Team

Clear ownership in building of the product (the HOW)

Product Management

Development Management

Project Management

Collaboration is required!


Partner with Product Management §  Frequent interactions assume:

§ Many decisions throughout life cycle §  Unified overall roadmap §  Success requires collaborating §  Roles will blend and sometimes cross over





Partner with Product Management §  Deciding which features are in scope


Possibly In Scope

In Scope

Out of Scope

BC

J F

K

L

I

D

E

G

HA

M


Decisionaker Description

Company Most concerned about the business

Employee The team producing the product or service

Customer Users and resellers

Introducing the Decision Pyramid §  Let’s group Stakeholders into decision makers

(“decisionakers”)





Introducing the Decision Pyramid §  Story Time…

§  Probability of failure § Decision to attempt all features §  It didn’t go quite as expected § What was the decision criteria?



Movie Time


Excerpt copyright © 1990, 20th Century Fox, Miller’s Crossing. Joel and Ethan Coen.




Introducing the Decision Pyramid §  Define how decisions are to be prioritized


1

#1 Decisionaker – the King of the Mountain, who generally makes the

decision?

?

Employee

Company

Customer

2 #2 -- Who is next most important if the #1 group can’t

decide?

3#3 – Last but definitely not least, Who provides the foundation that everyone relies on (when #1 and

#2 can’t decide)?


Introducing the Decision Pyramid §  So what does your Decision Pyramid look like?


1

3

2?

Employee

Company

Customer




Introducing the Decision Pyramid §  Here’s a sample Decision Pyramid that works


1

3

2

Employee

Company

Customer


Best Practice §  Keep decision criteria simple and intuitive §  Consistently apply Decision Pyramid

methodology §  Remind the staff by reinforcing how decisions

are made §  Take a lesson from Guy Kawasaki: “Make

meaning, not money.”







Clearly Define the Project Charter §  How many of you start a project with a Project

Charter document?





Clearly Define the Project Charter §  What it is

Provides the initial requirements to formally authorize a project

§  Who benefits Every Stakeholder knows what the project is all about



Clearly Define the Project Charter §  What is the output?

§ Designate a project manager §  Provide information § Objectives are set §  Results in the sponsor funding the project





Clearly Define the Project Charter §  What does it include?

§  Clarification of the business need §  Justification for the project § Defines market requirements §  Briefly describes the product or service



Best Practice §  According to the PMBOK ® Guide:

There is no project

if there is no Project Charter.





Agenda


Introduction to Agile Thinking

Topics: §  Quick Agile History Lesson §  Developing Quality Products the Agile Way §  Case Studies §  Why Focus is So Critical





§  Quick Agile History Lesson §  Started in 1986 with Fuji, Honda, Canon, … … decided to build products differently

1.  Small, cross-functional teams 2.  Work is timeboxed (fail early, fail quick) 3.  Adapt to change along the way



§  Quick Agile History Lesson §  Result: got to market faster, Japan shook its

“Made in Japan” stigma § Where did this concept came from anyway?





Quick Agile History Lesson §  Inspired by W.

Edwards Deming (an American!)

§  Belief that designed-in quality development requires frequent P-D-S-A cycles


Plan Do

StudyAct


Quick Agile History Lesson §  In 2001, a software development workshop

coined the term “agile” §  A number of competing agile software

methodologies were developed


Less structured, more adaptable

More structured,less adaptable

XPScrum WaterfallAd hoc

Agile




Quick Agile History Lesson §  Agile Alliance’s “The Agile Manifesto”

emphasizes time and team efficiency


Key Agile Principles

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


Quick Agile History Lesson §  Scrum is not an acronym, but a Rugby term §  Ken Schwaber and Jeff Sutherland created it

through evolution on a real project §  Formed the Scrum Alliance and …

… formalized Certified ScrumMaster training §  Over 40,000 trained to date §  Scrum is a key part of the “agile family”


Scrum isn’t just for software development,

neither!




Developing Quality Products the Agile Way §  Certified ScrumMasters act as project

managers, but they report to the team §  Customer (user) provides the guidance §  Fixed timeboxed delivery (no exceptions)



Developing Quality Products the Agile Way §  Self-managed teams, minimal bureaucracy §  Quality tests validate product along the way §  Co-located and focused, focused, focused, … §  Frequent communication and transparency





Developing Quality Products the Agile Way §  The Triple Constraint

is a popular PMBOK ® Guide concept ... ... with dependent relationships between scope, cost, and time


Quality

TimeCost

Scope


Developing Quality Products the Agile Way §  When the feature

set (scope) expands or the effort takes longer than expected ... ... cost and time expand ... not good!


Quality

TimeCost

ScopeExpand feature set

Quality

TimeCost

Scope




Developing Quality Products the Agile Way §  But with agile, the

Triple Constraint is turned upside down

§  Scope (feature set) is driven by predefined budget (cost) and schedule (time)


Quality

TimeCost

Scope

Quality

TimeCost

Scope


Process Groups

Implementation


Closing

Collect Requirements

Verify Scope

Define Scope Control Scope

Create WBS

Developing Quality Products the Agile Way §  Using the Scope Management knowledge area




Risk Im

pact

Time

Waterfall

Agile


Developing Quality Products the Agile Way


Agile projects attack risks early

… and risks steadily decrease near release


Developing Quality Products the Agile Way


Risk Im

pact

Time

Waterfall

Agile




Process Groups

Implementation


Closing

Plan Risk Management

Monitor and Control Risks

Identify Risks

. . .

Developing Quality Products the Agile Way §  Risk Management knowledge area



Case Studies §  Nokia §  Patient Keeper §  Symantec §  Salesforce.com §  Real Software





Why Focus is So Critical §  Habit is to multitask your senior staff §  According to Peopleware, you are at your best

when you reach “flow” §  According to Slack, immersion (or “emotional

inertia”) is what your want



Exercise §  Open your workbook and make 3 columns like

this:

§  You have 30 seconds to fill across the table §  Ready? §  Go!


Integers Letters (A, z) Roman

1 A I

… … …

26 Z XXVI




Exercise §  Open your workbook and make 3 columns like

this:

§  You have 30 seconds to fill down the table §  Ready? §  Go!


Integers Letters (A, z) Roman

1 A I

… … …

26 Z XXVI


Just the Facts §  You can measure this with this simple formula:

E-factor % = Uninterrupted hours Body-present hours

§  For example if you have 6 uninterrupted hours out of 8, your E-factor is 75%

§  If one person’s E-factor is 25% and another is 50% ... … the first worker has to work twice as hard





Why Focus is So Critical §  According to Tom DeMarco’s Slack, balancing

too many tasks carries a price!


01234567

1 2 3 4 5

Hou

rs o

f Pro

ducr

tivity

Projects Task Switching Per Day

Software Developer Productivity

A steady decline in available time (not to mention lack of focus)


Process Groups

Implementation


Closing

Develop Human Resource Plan

Acquire Project Team

Develop Project Team

Manage Project Team

Why Focus is So Critical §  Focus with the Human Resource knowledge area





Why Focus is So Critical §  Impact of excessive multitasking

§  Unhappy workers § Not living up to full potential §  Costs more §  Impacts the team

§  Let’s take just 1 minute and brainstorm … … What can you do to improve a team’s focus?






§  Is a New Process Methodology Needed? §  Align to Your Company Vision §  Introduction to Agile Thinking §  Overview of the Agile Workflow §  What Have We Learned?

Agenda


Overview of the Agile Workflow

Topics: §  Key Agile Roles §  The Agile Project Manager §  Introduction to XP §  Basic Scrum





Key Agile Roles §  Product Owner: Ultimately responsible for the

project’s success §  ScrumMaster: Coordinator, facilitator, and

obstacle-remover §  Development Team: Works to deliver the

project to market §  Customer: The ultimate authority, the Boss!

(Somebody must be the customer advocate)


In Agile, the Project Manager reports to the

team!


The Agile Project Manager §  It is all about being flexible …

… while adhering to a plan and a process


Less structured, more adaptable

More structured,less adaptable

XPScrum WaterfallAd hoc




Movie Time


Excerpt copyright © 1993, New Line Cinema, Gettysburg. Ron Maxwell.


Process Group Common Definitions

Initiating Starts these process cycles

Planning Establishes objectives and processes

Executing Implement processes (“do the work”)

Monitoring & Controlling

Track and apply improvements prior to beginning of the next implementation

Closing Ends the process cycles (Release!)

The Agile Project Manager





PDSA Process Group Common Definitions

Initiating Sets the vision, starts these process cycles

Plan Planning Establishes objectives and processes

Do Executing Implement processes (“do the work”)

Study Monitoring & Controlling


Act





The Agile Project Manager §  How PMBOK ® Guide process groups relate §  PDSA: Progressive elaboration is both a project

management concept and an agile concept


Monitoring and Controlling

Planning Executing

Initiating ClosingPlan Do

StudyAct




The Agile Project Manager §  PDSA: Agile can map onto PMBOK® Guide

process groups §  “Discover

and deliver” cycles iterate until the project is done


Monitoring and Controlling

Planning Executing

Initiating ClosingPlan Do

StudyAct


PDSA Process Group Common Definitions

Initiating Sets the vision, starts these process cycles

Plan Planning Establishes objectives and processes

Do Executing Implement processes (“do the work”)

Study Monitoring & Controlling


Act







Introduction to XP


1

Explore and create initial

Stories

2 Release Planning

Work performed: Pairs pick Story Cards, Create tests first, integrate, and validate often with the customer

4

Continue if Story Cards aren’t completed

3 Iteration Planning

Feature Description

Specifications Described as “stories”

Schedules Project will have a certain number of cycles

Sequence of Events Short cycle development, iterations follow another

Adaptable to Change Thrives on change

Easy to Understand Concept of pair programming can be confusing

Involve Customers Cohabitation with the team may not be possible


Introduction to XP





Show of Hands §  How many of you already build products

nightly? ____ §  How many of you have dedicated testers? ____ §  How many of you have invested in automated

testing tools and technology? ____ §  How many of you are lying? ____



Basic Scrum §  Timeboxed mini-development cycles §  Each

timebox is a fixed cycle

§  Each, a series of PDSAs


Iteration 1 Iteration

2

Iteration3

Timebox Timebox Timebox

Ok?

Are you kidding?

Ok?

Not bad, just not yet

Ok? “Let’s ship this pig!”

Plan Do

StudyAct




Best Practice

Agile Methodology is geared towards reducing complexity into small chunks

(“Sushi Delivery”) … The goal is for your team to

operate in a quality “delivery” rhythm … The mechanics are tough,

but the benefits can be great!



Basic Scrum §  Scrum flow is intuitive, customer-driven, and

emphasizes team collaboration


The Sprint

Meetings: Daily Scrum

Meeting: Sprint Planning

Meeting: Sprint Review

Product Backlog Sprint Backlog

1 2 3 4

Sprint

Ship!Meeting: Create Product Backlog

5

Work: Daily development,check-ins, builds,

and validation




Basic Scrum §  Step 1: Create the Product Backlog


The Sprint

Product Backlog

1

Meeting: Create Product Backlog


Basic Scrum §  Step 2: Sprint planning


The Sprint



1 2





Basic Scrum §  Step 3: The Sprint


The Sprint




1 2 3

Sprint



and validation


Basic Scrum §  Step 4: Sprint Review


The Sprint


and validation





1 2 3 4

Sprint





Basic Scrum §  Step 4: Sprint Review – Return for another

Sprint …


The Sprint


and validation





1 2 3 4

Sprint



Basic Scrum §  Step 5: Sprint Review – or release the product!


The Sprint


and validation





1 2 3 4

Sprint


5

ü



Feature Description

Specifications Chisel away at feature backlog

Schedules Fixed iterations

Sequence of Events One iteration follows another in 30 day “sprints”

Adaptable to Change Thrives on change

Easy to Understand Yes, few rules and very little documentation

Involve Customers At sprint reviews at the end of each cycle

Agile Software Project Best Practices

Basic Scrum §  Scrum Characteristics



Best Practice

A Scrum-built product is release-capable at the end of each Sprint …

… but may not be release-ready

We have rushed through a lot, we’ll cover this entire process in more detail later …




What Have We Learned?

The title of this training says it all: Deliver Software Projects On Time, Every Time

§  The software industry as a whole is generally not very productive

§  Waterfall technique isn’t adaptable to the work that needs to “be discovered”

§  Customer-centric project decisions succeed §  Embracing change (agile) transforms teams §  Project management best practices can be agile




§  Having a company vision and reinforcing that decision “tree” makes tough decisions easier

§  Embracing change (agile) transforms teams §  Project management best practices can be agile §  It is your job to keep staff focused §  Scrum discovers and is adaptable to change



Deliver Projects On Time, Every Time- PM 1

Agenda



How the Scrum Workflow Really Works

Topics: §  The Scrum "Walkabout" §  Ways That Scrum Can Fail





The Scrum "Walkabout" §  Scrum flow is intuitive, customer-driven, breaks

complex projects into pieces, and team-focused The Sprint





1 2 3 4

Sprint


5


and validation



The Scrum "Walkabout" §  Step 0: Create the Project Vision

§ Management sets the project direction §  Selects the team §  Identify “rules of engagement” §  Plan whatever you need to do before

launching the team §  But the longer you get started, the longer

you don’t get the product released


Step 0? Isn’t that the same as

Scrum Planning?

’fore I forgit – the Project Vision thang

should act as the Project Charter!




The Scrum "Walkabout" §  Use Rough Order

of Magnitude (ROM) technique

§  Estimate a range of Sprints where release will occur

§  (You can map key milestones on top)


+100%

+50%

+25%

+10%

-10%

-25%

-50%

Project initiation Project closureTime

Rough Order of Magnitude (ROM)+100%

+50%

+25%

+10%

-10%

-25%

-50%


Rough Order of Magnitude (ROM)

Definitive Estimate

+100%

+50%

+25%

+10%

-10%

-25%

-50%


Delivery range

+100%

+50%

+25%

+10%

-10%

-25%

-50%


Delivery range

TF IC


Best Practice

The benefit of incremental product building

“You’ll rarely be remembered for missing a feature …

but, you’ll never be forgotten for missing a schedule.”





The Scrum "Walkabout" §  Step 1: Create the Product Backlog

The Sprint

Product Backlog

1





§  Includes three ingredients 1.  Feature descriptions 2.  Consensus estimating 3.  Priorities based on value

§  Scrum relies on a team-driven, efficient method of defining the Product Backlog as Stories






§  Includes three ingredients 1.  Feature descriptions 2.  Consensus estimating 3.  Priorities based on value

§  Scrum relies on a team-driven, efficient method of defining the Product Backlog as Stories


Remember the Decision Pyramid?


The Scrum "Walkabout" §  Calculate a team member’s available time


Hours Time Usage This Week

40 Maximum hours available

-5 In meetings

-5 Supporting customers

-8 Other projects

-0 Vacation/holiday

22 Total remaining available hours (55%!)




Best Practice

Working more hours doesn’t mean that the team

produces more output … … for that very reason,

estimates must be realistic



The Scrum "Walkabout" §  Step 2: Sprint planning

The Sprint



1 2






The Scrum "Walkabout" §  Step 2: Sprint Planning

§  Remaining Product Backlogs are prioritized by the team (the Sprint Backlog)

§  Available team time is allocated §  The Sprint Backlog is subdivided into tasks

and level of effort §  Assignments and obstacles are identified §  The Sprint starts!



The Scrum "Walkabout" §  Step 2: Sprint Planning

§ How is level of effort (LOE) measured? §  PMBOK® Guide relies on expert judgment §  Technique used in Scrum planning (Step 1) §  It starts with a simple

card game …


13

3

1/2

?




The Scrum "Walkabout" §  Step 2: Sprint Planning – the game


What … Yapp, yapp, yapp, …, and more yapp

How … yapping,

yapping, …

133

1/2?

I thought it was long because …

I thought it was short because …

5 55

35 5


Open Discussion

What are the benefits to this method of estimating the level of effort?





The Scrum "Walkabout" §  Step 3: The Sprint

The Sprint




1 2 3

Sprint



and validation



The Scrum "Walkabout" §  Step 3: The Sprint

§  A Daily Scrum Meeting takes place with the team and the ScrumMaster

§  Three critical topics are covered 1.  What was just completed? 2.  What are you working on next? 3.  What is hindering progress?

§  Say, what’s burning?





The Scrum "Walkabout" §  Step 3: The Sprint – A Burndown chart of

remaining work is updated daily


0

5

10

15

20

25

30

35

DS1-W DS2-T DS3-F DS4-M DS4-T

Burndown Chart

Planned Actual

We more than caught up …

… eventually completing on time!

Actual work got behind


Best Practice §  The Daily Scrum meeting is the opportunity to

inspect and adapt §  It isn’t enough to just “engineer” the work …

… test validation is equally as important (the more automated the better!)





The Scrum "Walkabout" §  Step 4: Sprint Review

The Sprint


and validation





1 2 3 4

Sprint




The Scrum "Walkabout" §  Step 4: Sprint Review

§  Team presents product to the customer, Product Owner, and other stakeholders

§  Re-evaluate how to adjust practices and improve

§  Sprints need to complete (d-u-n-n) §  The team has a decision to make …





The Scrum "Walkabout" §  Step 4: Sprint Review – Return for another

Sprint … The Sprint


and validation





1 2 3 4

Sprint




The Scrum "Walkabout" §  Step 5: Sprint Review – or release the product!

The Sprint


and validation





1 2 3 4

Sprint


5

ü


I prefer to call this

the “Ship the Pig!” milestone




Best Practice

A Scrum-built product is release-capable at the end of each Sprint …

(… but may not be release-ready)



The Scrum "Walkabout" §  Scrum iterative cycles = progressive elaboration

(PMBOK® Guide) = PDSA (Deming) The Sprint


and validation





1 2 3 4

Sprint


5


Plan Do

StudyAct




Ways That Scrum Can Fail §  Typically 20% attrition during transition to agile

1.  Old-style programmer won’t change 2.  Poor performer(s) 3.  Not a “completer” – 95% almost done is not

really done (d-u-n-n) 4.  First-line managers don’t want to lose

control 5.  Team members being defensive



Ways That Scrum Can Fail §  Practicing “almost Scrum-like” §  No executive management commitment §  Force-fitting a project that isn’t suited to Scrum §  Not having basic iterative tools in place

§  Automatic build and source control §  Automatic tests and framework §  User documentation must be current






Agenda





Define Project Scope the First Time

Topics: §  Being Effective at Collecting Requirements §  Creating the Product Backlog (WBS) §  Verifying and Controlling Scope



Being Effective at Collecting Requirements §  What is a requirement anyway?

A feature definition that satisfies a customer need

And, according to IEEE: “Condition or capability needed by a user to solve a problem or achieve an objective.”





Being Effective at Collecting Requirements §  What is a requirement anyway?

And according to the PMBOK® Guide: The project and product features/functions needed to fulfill stakeholder’s needs and expectations.



Being Effective at Collecting Requirements §  The cost, according to Barry Boehm, of

correcting a requirement

“Up to 68 times more than if it had been found at requirements definition”





Best Practice Your role is to remove fear of accountability from

the staff that has probably been … … burned in the past!



Movie Time


Excerpt copyright © 1986, 20th Century Fox, Aliens. James Cameron.




Process Groups

Implementation


Closing


Verify Scope


Create WBS

Being Effective at Collecting Requirements §  Project Scope Management knowledge area



Best Practice If the project manager isn’t technical enough …

… partner with someone who is and make decisions as a

unified leadership team





Being Effective at Collecting Requirements §  Characteristics of a great set of requirements

§  Complete §  Correct §  Feasible § Necessary §  Traceable §  Verifiable

Copyright © Leading Software Maniacs, LLC. All Rights

Reserved.


Best Practice §  When putting your requirements together, why

not use a simple table as a checklist?


How good are my requirements?

ü Complete

ü Correct

Feasible

…




Being Effective at Collecting Requirements §  Interviews §  Facilitated workshops §  Brainstorming §  Questionnaires §  The Delphi Technique


Hey! I also like these to identify

risks …

Possibly In Scope

In Scope

Out of Scope


Being Effective at Collecting Requirements §  Deciding which features are in scope


BC

J F

K

L

I

D

E

G

HA

M

In ScopeMust Haves

Nice to Haves

BC

D

J F

K

L

I

E

G

HA

M

JI

BC

D




Being Effective at Collecting Requirements §  Possible group decision-making techniques

§  Unanimity Everyone agrees or it isn’t prioritized




§ Majority Rule At least 50% agree






§  Consensus Majority agrees and the minority agrees to support the decision




§ Dictatorship Individual makes the final decision





Best Practice §  Regardless of which group decision-making

technique is used … §  Encourage a team culture based on effective

communications and team buy in §  The team cannot become absorbed with every

detail §  Product Owners need to account for more

detail while focusing on the user experience



Being Effective at Collecting Requirements §  What are the key risks if requirements aren’t

done right? §  Product not accepted by the customer §  Creeping user requirements result in project

overruns and team morale issues §  Ambiguous requirements are impossible to

verify (test) § What’s worse, on-time delivery isn’t possible





Creating the Product Backlog (WBS) §  Agile projects need a scope roadmap, too!

The Sprint





1 2 3 4

Sprint


5


and validation



Process Groups

Implementation


Closing


Verify Scope


Create WBS

Creating the Product Backlog (WBS) §  Project Scope Management knowledge area





Creating the Product Backlog (WBS) §  You need to breakdown the project into

manageable work components §  Why?

1.  Eliminates Scope Creep 2.  Once you complete the work components,

the project should be complete 3.  Optionally deliver early by prioritizing those

backlog items with customer value first



Creating the Product Backlog (WBS) §  Basic work package creation flow



Define Scope

Analyze the work to meet project objectives

“Work Packages” (WBS and WBS

Dictionary)




Creating the Product Backlog (WBS) §  The Work Package is the lowest level that can be:

§  Scheduled §  Cost estimated § Monitored §  Controlled



Creating the Product Backlog (WBS) §  Sample hierarchical work packages


2 UI 3 Core Calculation “engine”

3.2 Tax Calculations

3.1 Shipping/Handling

Calculations

3.2.1 Build state tax software

module

Overall modules, details aren’t yet known

“Packages”are known but, need

more detail

Ah ha! Finally the Work Package




Creating the Product Backlog (WBS) §  What defines the product feature set? Project Work = sum(Work Package1, WorkPackage2, …)

§  And how does this relate to agile projects? Project Work = Sprint1( sum(Work Package1, WorkPackage2, …)) + Sprint2(sum(Work Package1, …)) + …


So, my project is defined by the combined work

packages? L-I-B!

`

PB ST WBS Dictionary and Task Description PB.ST DS1-W DS2-T DS3-F DS4-M DS5-T SR-T01 01 WBS Dictionary 1 01.01 001 01A SubTask 1 01.01A 001 01B SubTask 2 01.01B 3 3 2 101 02 WBS Dictionary 2 01.02 8 8 6 2 401 01 SubTask 1 01.01 13 13 12 4 302 03 WBS Dictionary 3 02.03 5 5 7

29 29 27 7 7 0

Orig: 29 29 22 13 4 0

Remaining HoursProduct Backlog Tasks


Verifying and Controlling Scope §  Daily Scrums throughout the iterative process §  Keeps team focused, controls scope §  Remaining hours per task goes to 0 when verified


ü




Best Practice §  Use the creation of a Product Backlog (WBS

and the WBS Dictionary) as a cross-functional team building exercise






Agenda



Successfully Transition to an Agile Organization

Topics: §  Case Studies About Developer Motivation §  Using Organizational Theory to Develop Teams §  Establish a Culture of Effective Communications





Process Groups

Implementation


Closing

Develop Human Resource Plan

Acquire Project Team

Develop Project Team

Manage Project Team

Human Resource Knowledge Area §  Motivating and leading teams through change



Movie Time


Excerpt copyright © 1999, 20th Century Fox, Office Space. Mike Judge.




Case Studies About Developer Motivation §  According to a recent IEEE Computer Society

study, Tracy Hall concludes motivation has four key impacts


Project Team

Motivates

Productivity

Quality

Success

RetentionYou!


Case Studies About Developer Motivation §  Back in the 1980s:

Developers enjoyed learning and being challenged … … but had little interest in socializing

§  Recently: Shift where motivation has a lot to do with personality and their working environment …





# Motivational Factor Highlights

1 Identification with task Clear goals, team identifies with product quality

2 Great management Direction is known, effective communications

3 Employee participation Involved, working with others is a positive

4 Career path Opportunities, knows what is expected

5 Variety of work Learning, making use of skills, being “stretched”

Case Studies About Developer Motivation §  Important motivational factors for developers


No wonder motivational “enticements” aren’t effective with the “nerd herd”


Best Practice §  According to Project Management Practitioner’s

Handbook, you can dramatically enhance an employee’s satisfaction §  Job rotation §  Job enlargement





Using Organizational Theory to Develop Teams §  Basic theories that every manager should know

§ Maslow’s Hierarchy of Needs § McGregor’s Theory X and Theory Y § Hierarchy of Needs combined with Theory X

and Theory Y §  Tuckman’s Team Development model



Using Organizational Theory to Develop Teams §  Maslow’s

Hierarchy of Needs


Self-Actualization SA

Esteem

Acceptance

Security

Physiological

Higher needs

Lower needs




Definition Highlights

Physiological Basic biological/workplace needs

Security Freedom fear, company is growing, stable management

Acceptance Part of the team, accepted, key participant

Esteem Feeling of importance, recognized, clear career path

Self-Actualization Working to full potential, passionate, love their work

Using Organizational Theory to Develop Teams §  Maslow’s Hierarchy of Needs



Using Organizational Theory to Develop Teams §  Theory X

organizations take a lot more management

§  Theory Y allows you to lead


“I work ‘cause I have to”

Theory XDistrust,

micromanage staff

You


Theory XDistrust,

micromanage staff

“I work ‘cause I want to”

You

Theory YConfidence and

trust,empower staff


Theory XDistrust,

micromanage staff

“I work ‘cause I want to”

You

Theory YConfidence and

trust,empower staff




Need Theory X Theory Y

Staff members Not motivated to work Very motivated, strong desire to work

Management (you!)

Forced to micromanage Empower the team to do the work

Overall theme Distrust between staff and management

Trust between staff and management

Using Organizational Theory to Develop Teams §  McGregor’s Theory X and Theory Y



Using Organizational Theory to Develop Teams §  McGregor’s Theory Y organizations benefits

§  You can focus on removing barriers for the team

§ When staff wants to do well, “untapped energy” and creativity takes place

§  Prevailing belief of a high degree of job satisfaction in doing a great job





Using Organizational Theory to Develop Teams §  Hierarchy of

Needs combined with Theory X and Theory Y


Theory Y

Theory X

SA

Esteem

Acceptance

Security

Physiological

Higher needs

Lower needs


Using Organizational Theory to Develop Teams §  Bruce Tuckman developed a team-development

psychology back in 1965 §  It is still taught to this day …

… and forgotten about the day after it is taught §  Premise is that a team transitions through, at

most, five distinct stages during a project


* You might call these

stages HELL!




Best Practice

Why care about the Tuckman Team Development model?

1.  Your role is generally to direct the team 2.  But your communication and leadership

style should adjust depending on the stage



Using Organizational Theory to Develop Teams §  The Tuckman Team Development model

1.  Forming 2.  Storming 3.  Norming 4.  [Performing] 5.  Adjourning


Forming Why are we here and what should we

do?

Storming How much power do I exert?

Norming Together for the common good

Autonomous team without need for

supervision (rare!)Performing

AdjourningThe project is over,

NOW what?




Stage What Happens? Your Leadership Style

Forming Team agrees on project goals, members are on their best behavior, level of trust develops

Validation

Each member should be able to recite the 30-second “elevator speech”

Using Organizational Theory to Develop Teams

§ Forming


Directive



Storming Conflict, anxiety, and open expression of ideas

Validation

This stage is necessary for team development and ultimately can produce better software products


§ Storming


Listening *

* with directive reinforcement

You may have to go back to Forming if your team never really unified!





Norming Trust, relationship building, success takes shape

Validation

Maintaining this model takes constant attention, if teamwork starts to break down or team members become confrontational, you are really back in the Storming stage


§ Norming


Participative *

* with feedback cross-checks



Performing High-performing results, team is unified

Validation

Team almost runs without any management at all!


§ Performing


Participative

Remember when we talked about focus? A team in the “flow” is a

performin’ team.





Adjourning Project closure tasks are performed, teams disband

Validation

Can be both positive or negative, the focus is to ensure that the spirit of lessons learned are openly discussed to improve the organization—you must have a transition plan


§ Adjourning (aka Mourning)


Proactive


Show of Hands §  Pick one of your current teams §  Where are they in Tuckman’s model? §  Your goal is to move the team to the right


Forming Storming NormingAdjourning

Performing




Establish a Culture of Effective Communications §  In Ed Yourdon’s Death March, he states some

very important communications rules §  Total transparency §  Clear communication of risks

§  By the way, full transparency is an agile (Scrum) requirement



Just the Facts

Your team expects you to communicate

According to the PMBOK® Guide, about 90% of your time

should be spent communicating!





Process Groups

Implementation


Closing

Identify Stakeholders

Plan Communications

Distribute Information

Report performance

Manage Stakeholder Expectations

Human Resource Knowledge Area §  Communicating through change and project

delivery



Establish a Culture of Effective Communications §  Understand your Stakeholders


You! The Communicator!

Not supportive

Interested Supportive

Very supportive

information

Stakeholders

information information

information




Establish a Culture of Effective Communications §  Being absolutely clear and transparent



Best Practice

Your project’s success depends on how effectively you communicate






§  As long as you stick to agile (Scrum) roles and responsibilities, your projects should be successful

§  Keeping project scope “in check” (no gold plating) will make all of the difference

§  Understanding basic individual and team motivational theory should help retain staff and reduce project risk




§  Last, but not least, effective communications techniques will set your team apart and reduce project risk

§  Throughout this presentation we’ve shown how the basics of the PMBOK® Guide can be applied to your agile project





References §  Agile Alliance. Manifesto for Agile Software Development

(www.agilealliance.org). §  Agile Alliance. Declaration of Interdependence (www.pmdoi.org). §  Beck, Kent. Extreme Programming Explained: Embrace Change, Second

Edition. Boston: Addison-Wesley, 2005. §  Boehm, Barry, J.R. Brown, and M. Lipow. “Quantitiate Evaluation of

Software Quality,” Second IEEE International Conference on Software Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1976.

§  Connolly, Mickey and Richard Rianoshek. The Communication Catalyst: The Fast (But Not Stupid) Track to Value for Customers, Investors, and Employees. Chicago: Dearborn trade Publishing, 2002.



References §  Cohn, Mike. Agile Estimating and Planning. Upper Saddle River, NJ:

Pearson Education, 2006. §  Davis, Alan M. Software Requirements: Objects, Functions, and States.

Englewood Cliffs, NJ: PTR Prentice Hall PTR, 1993. §  DeCarlo, Doug. eXtreme Project Management: Using Leadership,

Principles, and Tools to Deliver Value in the Face of Volatility. San Francisco: Jossey-Bass, 2004.

§  DeMarco, Tom. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. New York: Random House, 2002.

§  DeMarco, Tom and Timothy Lister. Peopleware: Productive Projects and Teams, 2nd Edition. New York: Dorset House Publishing, 1999.

§  Dr. Dobb’s Portal. The Agile Manifesto. www.ddj.com. J. Wiley and Sons, 1994.





References §  Jones, Capers. Applied Software Measurement: Global Analysis of

Productivity and Quality, Third Edition. New York: McGraw-Hill, 2008. §  Hall, Tracy, Helen Sharp, Sarah Beecham, Nathan Baddoo, and Hugh

Robinson. “What Do We Know About Developer Motivation?” IEEE Software, July/August 2008, 25(4), pp. 92-94 (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4548414).

§  IEEE. IEEE Std 830-1998: “IEEE Recommended Practice for Software Requirements Specifications.” Los Alamitos, CA: IEEE Computer Society Press, 1998.

§  Kawasaki, Guy. “Entrepreneurship’s 10 Commandments.” Forbes. Jun 11, 2009 (www.forbes.com/2009/06/11/guy-kawasaki-wharton-entrepreneurs-management-wharton.html).



References §  Kliem, Ralph L. and Irwin S. Ludin. Project Management Practitioner’s

Handbook. New York: AMACON, 1998. §  Larman, Craig. Agile and Iterative Development: A Manager’s Guide.

Boston: Pearson Education, 2004. §  McConnell, Steve. Rapid Development: Taming Wild Software

Schedules. Redmond, WA: Microsoft Press, 1996. §  Mulcahy, Rita. PM Crash Course: Tricks of the Trade for Project

Managers. Minneapolis: RMC Publications, 2006. §  Newkirk, James and Robert C. Martin. Extreme Programming in

Practice. Boston: Addison-Wesley, 2001.





References §  Project Management Institute, Inc. A Guide to the Project Management

Body of Knowledge: PMBOK® Guide, 4th Edition. Newton Square, PA: Project Management Institute, 2008.

§  Schwaber, Ken. Agile Project Management with Scrum. Redmond, WA: Microsoft Press, 2004.

§  SD Times. Taking the Extreme Out of XP Methods. www.sdtimes.com. Feb 1, 2005.

§  Takeuchi, Hirotaka and Ikujiro Nonaka. The New New Product Development Game. Harvard Business Review. Jan-Feb 1986.

§  The Standish Group. Chaos Reports (1994-2006). www.standishgroup.com.



References §  Whitaker, Ken. Principles of Software Development Leadership:

Applying Project Management Principles to Agile Software Development. Boston: Course Technology PTR, 2009.






Review the Handouts






www.leadingswmaniacs.com/seminars.html


Applying Project Management Principles to Software Development Leadership, Principles of Software Development Leadership, 4Ps, Leading Software Maniacs, Soft-Audit, jus’ e’nuff, Nerd Herd Game, the 4Ps logo, the Leading Software Maniacs logo, and the Nerd Herd Game logo are marks of Leading

Software Maniacs, LLC. PMI, PMP, PMBOK, the PMI logo, and the PMI Registered Education Provider logo are registered marks of the Project Management Institute, Inc.

Deliver Projects On Time, Every Time

Technology

Transcript of Deliver Projects On Time, Every Time