Rsdc Nppm01

1

IBM Rational Software Conference 2009

NPPM01

Software Development “Worst Practices”: Cautionary Tales From the Front

Kurt BittnerCTO - Americas, Ivar Jacobson International

[email protected]

Tom WeinbergerGeneral Manager, The Nimblestar Group, Inc

[email protected]

NPPM01

© 2009 IBM Corporation1

mailto:[email protected]

mailto:[email protected]

http://www.ibm.com/software/rational

21


NPPM01

10. The Budget Planning Game

21

Things You Don’t Want to Be Doing on a Software Project

What would the PHM do?

4


NPPM01

Worst Practice: The Budget Planning Game

• Planning with no idea of what is really needed- A paragraph of description- A guess at a budget, and- VOILA! A project is chartered

4

• Committing to budget and schedule based on conjecture… - Then pretending the commitments are real

Until they are not!

5


NPPM01

Better Practice: A rational funding model

• Fund the Project in Phases• Inception: validate that the required business

benefits are reasonably achievable• Elaboration: validate that the cost to build will

not exceed the required rate of return• Construction & Transition: fund the completion

and delivery of the solution

• Focus more closely on validating the business case• Validate the “cost envelope”: the amount of

investment, at the required rate of return, that you would be willing to spend to obtain the benefits desired

5

21


NPPM01


9. Scope Sprinting

21



7


NPPM01

Worst Practice: Scope Sprinting

• Never saying “No”

• Having to accelerate schedules or add to workload and risk because of an inability to say no

• Coding right up to release day to add new things; still implementing new features in the Transition phase.

7

• Fixed schedule, budget and expanding scope

• Adding new features without reducing scope because “the business wants it” (without adding budget or time)

8


NPPM01

Better Practice: Managing scope continuously

• Start managing scope on Day 1• Constantly evaluate new requests

against outstanding work • Force rank all requirements• Draw a line: Above is “In”, below is

“Out”• Adding new work above the line

bumps some work below the line• Require the business to front the

additional cost

• Plan for multiple releases• Out of scope means “move to

consideration for next release”

8

21


NPPM01


9. Scope Sprinting

8. Project Juggling

21



10


NPPM01

Worst Practice: Project Juggling

• Spreading people across many too many projects

• Aligning people with silos, not business results

• Partial commitment to everything, total commitment to nothing

• Over committing due to conflicting priorities

• Not load balancing all projects to resources

10

11


NPPM01

Better Practice: A dedicated staffing model

• Broaden skills• Augment staff skills through training and

practice to enhance their capabilities

• Provide for right sizing strategies• Don’t start more projects than you have

resources to handle• Identify “Stealth Projects” and make them

official or kill them• Prioritize projects based on strategic

business need and KTLO need

11

• Serialize the projects• Assign people to 1 project at a time

• they will finish faster• Sequence projects more effectively

• Even the last project will finish sooner due to fewer “context switches”

21


NPPM01


9. Scope Sprinting

8. Project Juggling

7. Learning by training, not doing

21



13


NPPM01

Worst Practice: Learning by training, not doing

• Train at the beginning of a project for work at the end• Training has an intense half life• Learned skills diminish by 50% a

day unless used

• Skills taught by those still learning them• Inexperienced teachers applied to

the task of educating others• “You have the book on your shelf,

you must be an expert by now”

13

• Courses taught from endless PowerPoint slides and a few lame exercises

14


NPPM01

Better Practice: Learning by doing

• No amount of explanation is a substitute for actual experience

• Apply “just in time” methods to training

• Train just enough to get started

• Remember: learning requires practice• Expect mistakes• Account for the extra time needed

• Celebrate successes

14

21


NPPM01


9. Scope Sprinting

8. Project Juggling


6. Death by Documents

21



16


NPPM01

Worst Practice: Death by documents

• Filling out templates • with no idea of why• just because “the process” said

so…• Even though no one else is going

to use them

• Using documents to communicate• in place of face-to-face

communication

• Using all the RUP artifacts• “they would not have defined

them if they were not all needed”

16

Is your “document repository” looking more like an “electronic landfill?”

17


NPPM01

Better Practice: Communicate Face to Face

• Use a few key artifacts• To document decisions / results /

action items• As Learning tools • For maintainability / system

expansion• For capturing future enhancements

17

• Do not use documents to communicate• Documents don’t convey emotion• Talk to people• Preferably face to face – in front of a whiteboard, or looking at

prototypes• Interact!

21


NPPM01


9. Scope Sprinting

8. Project Juggling



5. Define, Publish, and Ignore

21



19


NPPM01

Worst Practice: Define, publish and ignore

• Spend lots of time defining a process

• Publish it with great fanfare

• Hold a few orientation training sessions to familiarize people with the process

19

• Decree that the process shall be followed

• Declare victory

• Move on to something else

20


NPPM01

Better Practice: Change behaviors, not processes

• Changing behaviors requires a couple of things:• Basic knowledge of concepts and how to

get started• Practice• Feedback from an experienced coach

20

• Resistance to change usually occurs because of lack of confidence in success• Coaching and practice improve confidence• A team culture that is tolerant of learning from errors is important

21


NPPM01


9. Scope Sprinting

8. Project Juggling




4. The Blame Game

21



22


NPPM01

Worst Practice: The Blame Game

• Using sign-offs to assign blame• If requirements are

wrong, make it the customer’s fault

• Using sign-offs to avoid and distribute responsibility• Make sure that if things

go wrong everyone will be implicated

22

23


NPPM01

Better Practice: Shared Success

• Reward the team for success• Absent team results, individual performance does not matter• Tie individual compensation and rewards to team contribution

23

• Focus on business results• A good architecture, requirements

spec, test plan matters not at all if the business results are not achieved

• Because of this, the “business” needs to be on the team, too

• “Project Juggling” nearly always prevents real teams from forming• A person can only be committed to

a very few things at a time

21


NPPM01


9. Scope Sprinting

8. Project Juggling




4. The Blame Game

3. Coding is mandatory, testing is optional

21



25


NPPM01

Worst Practice: Coding is mandatory, testing is optional

• Consider coding done when the code is checked in, not when it finally works right

• When running short of time, cut back on testing

• Assume one test cycle is enough

25

• Act as though coding is the only thing that counts

• Pretend that developers know more than even the customer about what they need

26


NPPM01

Better Practice: It’s only done when it’s passed testing

• Don’t count work as complete until testing is successful• Backlog items: Requirements, Defects, Change Requests,

Work Items…• “Percent Complete” is either 0% or 100%

• When you define a Backlog item, define how you will test it• This may be enough for many requirements• Be clear about what “pass” and “fail” mean

• Make testing a key measure of project health• If test coverage is low, you’re in trouble• Communicate results broadly

26

Remember: Customers will forget late delivery but not low quality

21


NPPM01


9. Scope Sprinting

8. Project Juggling




4. The Blame Game


2. Cutting off your head to save money

21



28


NPPM01

Worst Practice: Cutting off your head to save money

• Outsource critical functions to save money Understanding the business process Understanding needs Defining solutions Defining and managing the architecture

• Fail to develop staff skills to save money Cutting coaching and mentoring,

especially Discouraging the improvement of skills

because you perceive it to be a distraction

28

29


NPPM01

Better Practice: Recognize that requirements and architecture are your business• An understanding of the business

domain and what your organization needs is your business• It is what uniquely differentiates you• It is your opportunity for competitive differentiation• It is worth investing in competency in these areas

• Some work can be safely outsourced• Once the needs are understood• Once the solution is defined• Once the architecture is stable• Once the acceptance criteria for work is defined

• For outsourcing to be effective, specs must be precise• Clear deliverables, interfaces and acceptance criteria are

essential29

21


NPPM01


9. Scope Sprinting

8. Project Juggling




4. The Blame Game



1. “We don’t have to do that, we’re Agile!”

21



31


NPPM01

Worst Practice: We don’t have to do that, we’re Agile!

• Take the position that agile means not doing all the stuff you don’t like:• requirements, architecture, documentation, project planning, project

management, or anything other than coding...

31

32


NPPM01

Better Practice: Use risk reduction to guide your choice of practices

• Use appropriate practices to reduce risks and improve your chances at success• Requirements practices can reduce the risk that you may misunderstand what to build• Architecture practices can reduce the risk that the system may lack robustness• Planning practices can reduce the risk that something important may go missing

32

Risk

Time →

• Make conscious decisions about practices• There is no magical approach that

guarantees success• There are only techniques that, when

appropriately applied, improve your chances of success

21


NPPM01



9. Scope Sprinting

8. Project Juggling




4. The Blame Game



1. “We don’t have to do that, we’re Agile!”

21



34NPPM01


35NPPM01

© Copyright IBM Corporation 2009. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

Rsdc Nppm01

Business

software project

nppm01 nppm01

project juggling

ibm corporation

better practice

budget planning game

scope sprinting

rational funding model