deliver projects on time, every time

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

Initiating Planning Execution Monitoring & Controlling

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

Ship!Meeting: Create Product Backlog

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


What Have We Learned?

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

§  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

Technology

leading software maniacs

time overrunschaos

new process methodology

large projects

resolution of projects

agile workflow

disclaimerthis class

right class