Upload
thomas-weinberger
View
214
Download
0
Tags:
Embed Size (px)
DESCRIPTION
The Wrong Stuff Bad to worse practices that kill projects -or- The best of the worst Categorizing the top ten worst practices by RUP discipline.
Citation preview
1
IBM Rational Software Conference 2009
NPPM01
Software Development “Worst Practices”: Cautionary Tales From the Front
Kurt BittnerCTO - Americas, Ivar Jacobson International
Tom WeinbergerGeneral Manager, The Nimblestar Group, Inc
NPPM01
© 2009 IBM Corporation1
21
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
NPPM01
10. The Budget Planning Game
9. Scope Sprinting
21
Things You Don’t Want to Be Doing on a Software Project
What would the PHM do?
7
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
NPPM01
10. The Budget Planning Game
9. Scope Sprinting
8. Project Juggling
21
Things You Don’t Want to Be Doing on a Software Project
What would the PHM do?
10
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
NPPM01
10. The Budget Planning Game
9. Scope Sprinting
8. Project Juggling
7. Learning by training, not doing
21
Things You Don’t Want to Be Doing on a Software Project
What would the PHM do?
13
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
NPPM01
10. The Budget Planning Game
9. Scope Sprinting
8. Project Juggling
7. Learning by training, not doing
6. Death by Documents
21
Things You Don’t Want to Be Doing on a Software Project
What would the PHM do?
16
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
NPPM01
10. The Budget Planning Game
9. Scope Sprinting
8. Project Juggling
7. Learning by training, not doing
6. Death by Documents
5. Define, Publish, and Ignore
21
Things You Don’t Want to Be Doing on a Software Project
What would the PHM do?
19
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
NPPM01
10. The Budget Planning Game
9. Scope Sprinting
8. Project Juggling
7. Learning by training, not doing
6. Death by Documents
5. Define, Publish, and Ignore
4. The Blame Game
21
Things You Don’t Want to Be Doing on a Software Project
What would the PHM do?
22
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
NPPM01
10. The Budget Planning Game
9. Scope Sprinting
8. Project Juggling
7. Learning by training, not doing
6. Death by Documents
5. Define, Publish, and Ignore
4. The Blame Game
3. Coding is mandatory, testing is optional
21
Things You Don’t Want to Be Doing on a Software Project
What would the PHM do?
25
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
NPPM01
10. The Budget Planning Game
9. Scope Sprinting
8. Project Juggling
7. Learning by training, not doing
6. Death by Documents
5. Define, Publish, and Ignore
4. The Blame Game
3. Coding is mandatory, testing is optional
2. Cutting off your head to save money
21
Things You Don’t Want to Be Doing on a Software Project
What would the PHM do?
28
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
NPPM01
10. The Budget Planning Game
9. Scope Sprinting
8. Project Juggling
7. Learning by training, not doing
6. Death by Documents
5. Define, Publish, and Ignore
4. The Blame Game
3. Coding is mandatory, testing is optional
2. Cutting off your head to save money
1. “We don’t have to do that, we’re Agile!”
21
Things You Don’t Want to Be Doing on a Software Project
What would the PHM do?
31
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
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
IBM Rational Software Conference 2009
NPPM01
Things You Don’t Want to Be Doing on a Software Project
10. The Budget Planning Game
9. Scope Sprinting
8. Project Juggling
7. Learning by training, not doing
6. Death by Documents
5. Define, Publish, and Ignore
4. The Blame Game
3. Coding is mandatory, testing is optional
2. Cutting off your head to save money
1. “We don’t have to do that, we’re Agile!”
21
What would the PHM do?
IBM Rational Software Conference 2009
34NPPM01
IBM Rational Software Conference 2009
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.