MANAGEMENT’S ROLE

1/16/2002 Copyright © 2001, Net Objectives 152

 Continuous Overtime Is
Counterproductive
• Working more hours does not increase productivity
• Overwork is usually an indication of something
wrong - working more doesn’t fix the problem -
only the symptom
• We cannot take the attitude - we’ll mistreat our
people in the short run so there will be a long-run.

• If we make work fun, people will want to do more

of it. What’s overtime is an individual decision.
• Sometimes there are crunches - but it shouldn’t be a
way of life.

1/16/2002 Copyright © 2001, Net Objectives 153

 Management Strategy

• Metrics
• Tracking
• Risk mitigation
• Coaching
• Intervention

1/16/2002 Copyright © 2001, Net Objectives 154

 Management Strategy
Metrics
• Must measure estimates
• Must measure efforts
• Must measure results

• Else can’t know what is going on!

1/16/2002 Copyright © 2001, Net Objectives 155

 Management Strategy:
Metrics - Actual Productive Time (APT)
• An APT is a unit of real time spent on development.
– can use hours or days (not weeks)
• Depending upon the individual, 20-35 APT hours
are available per week.
• Each developer should estimate their available APT
hours per week
• At the end of each week, they should track what
APT hours they actually achieved
• If you are tracking your hours, these will often
correlate with billable hours

1/16/2002 Copyright © 2001, Net Objectives 156

 Management Strategy:
Metrics - For Each Task
• Estimate amount of actual productive time required
• Track actual time spent (approximately) doing a task

1/16/2002 Copyright © 2001, Net Objectives 157

 Management Strategy:
Metrics - Using Metrics to Improve Estimation

• You will now be tracking how much work it

should take to complete a task and how much
work you get done in a week
• This should enable you to estimate the calendar
time required to complete a task
• If this time does not match reality, adjust basis for
estimation

1/16/2002 Copyright © 2001, Net Objectives 158

 Management Strategy:
Metrics - For Example
• Task 123 should take 20 APT hours.
• John typically gets 20 APT hours per week.
• He therefore says he can get the job completed in
a week.

1/16/2002 Copyright © 2001, Net Objectives 159

 Management Strategy:
Metrics - Scenario 1
• John, in fact, takes 2 weeks to complete the
project.
• If we see that John was getting 20 APT hours per
week, then John misestimated the difficulty of the
task.
• If this happens consistently, we may want to
employ a weighting factor for John.

1/16/2002 Copyright © 2001, Net Objectives 160

 Management Strategy:
Metrics - Scenario 2

• John, in fact, takes 2 weeks to complete the project.

• If we see that John was getting only 10 APT hours per
week, then John correctly estimated the difficulty of the
task (good work John).
• Unfortunately, John is being distracted from his
development duties by other things (hence, the low APT
hours per week).
• Either Johns APT estimate per week needs to be
evaluated, or corrections need to be put in place so it can
return to normal

1/16/2002 Copyright © 2001, Net Objectives 161

 Management Strategy:
Metrics - In Reality
• Of course, in reality, typically neither extreme happens
-- but rather a case in between
• However, tracking the following metrics:
– expected vs actual APTs per week
– expected vs actual calendar time per task
• Gives us the ability to see if the problem is in focus of
personnel or in poor estimation.
• Lack of focus may be due to higher overhead than
necessary
• Poor estimation may be due to inexperience or high
risks (unknowns)

1/16/2002 Copyright © 2001, Net Objectives 162

 Management Strategy:
Tracking
• Need to see how people’s estimates match with
their reality.
• Need to make sure resources are what they are
supposed to be.
• Need to verify within an interval that progress is
being made at the right rate.

1/16/2002 Copyright © 2001, Net Objectives 163

 Management Strategy:
Risk Mitigation
• Risks should be tracked.
• Resources are limited, worst risks analyzed and
dealt with.

1/16/2002 Copyright © 2001, Net Objectives 164

 Management Strategy:
Constraint List
• Must also maintain a list of constraints.
• Not management’s role to find contraints -- just to
maintain it.

1/16/2002 Copyright © 2001, Net Objectives 165

 Management Strategy:
Coaching
• Management of the project is more about
removing obstacles and empowering the team
• Team should become self-directed

1/16/2002 Copyright © 2001, Net Objectives 166

 Management Strategy:
Intervention
• If team is not performing as needed, intervention
may be required.
• Difficult decisions, including personnel decisions,
are the manager’s responsibility.
• It is the manager’s responsibility to see that
processes are being followed.
– iterations
– risks
– testing

1/16/2002 Copyright © 2001, Net Objectives 167

 Summary
• Quicker feedback
– achieved through short iterations
• Full-time customer availability
– improves and quickens feedback
• Better playing of roles
– have the right people make the right decisions
• Automated and complete testing
– eliminates wasted manual effort
• Metrics
– make sure you know how much and on what people are
working
• Frequent integration
– eliminate integration bottlenecks

1/16/2002 Copyright © 2001, Net Objectives 168

 Summary
• Integrated, Iterative, Incremental development
• Quicker feedback
– achieved through short iterations
• Full-time customer availability
– improves and quickens feedback
• Better playing of roles
– have the right people make the right decisions
• Automated and complete testing
– eliminates wasted manual effort
• Metrics
– make sure you know how much and on what people are working
• Frequent integration
– eliminate integration bottlenecks
1/16/2002 Copyright © 2001, Net Objectives 169
 Adopting Agile Modeling

• Make the paradigmatic leap first.

• Implement one practice at a time

– Do your worst one
– Then do another one (your next worse one)

• Easier with new team

1/16/2002 Copyright © 2001, Net Objectives 170

 Acknowledgements
• Many of these notes are a paraphrasing of the book:
Extreme Programming Explained: Embrace Change
by Kent Beck.
• If you are serious about learning XP, you should get a
copy of this book. At a minimum, read the following:
– Preface – Enough, pgs xviii – xix
– Chapter 4 – Four Variables, pgs 15-19
– Chapter 5 – Learning to Drive, pg 27
– Chapter 10 – A Quick Overview
• The Planning Game, pg 55
• Refactoring, pg 58
• 40 Hour Week, pg 60
– Chapter 12 – Management Strategy, pgs 71-76
– Chapter 14 – Splitting Business and Technical Responsibility, pgs 81-84
– Chapter 15 – Planning Strategy, pgs 85-96

1/16/2002 Copyright © 2001, Net Objectives 171

 Bibliography - Web Resources
• http://www.netobjectives.com - Net Objectives
main site
• http://www.netobjectives.com/lpa/index.html --
Net Objectives XP site

• Jim Highsmith, Cutter Consortium, “Extreme

Programming”
http://www.cutter.com/ead/ead0002.html

• Scott Ambler - Agile Modeling Home Page

– http://www.agilemodeling.com/

1/16/2002 Copyright © 2001, Net Objectives 172

 Bibliography - Common
Lightweight Methodologies
• Extreme Programming (XP)
– www.netobjectives.com/xp
– www.xprogramming.com
– www.extremeprogramming.org
• Adaptive Software Development
– www.adaptivesd.com
• SCRUM
– http://www.controlchaos.com/
• Crytal Clear
– Alistair Cockburn’s web-site
(http://members.aol.com/acockburn/)
• Feature Driven Development
– Java Modeling in Color with UML, Peter Coad
• Agile Alliance
– http://www.agilealliance.org/
1/16/2002 Copyright © 2001, Net Objectives 173
 Bibliography - Books
• UML and Process Books
– Applying Use Cases: A practical Guide, Schneider,
Winters
– Use Case Driven Object Modeling With Uml : A
Practical Approach, Rosenberg, Scott
– Cognitive Patterns: Problem-Solving Frameworks for
Object Technology, Gardner
– UML Distilled, Fowler

• XP Books:
– Extreme Programming Installed, Jeffries
– Extreme Programming Explained, Beck
– Planning Extreme Programming, Beck, Fowler

1/16/2002 Copyright © 2001, Net Objectives 174

 Bibliography - Books cont’d
• Other useful books:
– Design Patterns Explained: A New Perspective on
Object-Oriented Design, Shalloway, Trott
– Design Patterns: Elements of Reusable Object-Oriented
Software, Gamma, Helms, Johnson, Vlissides
– Java Design, Coad
– Multiparadigm Design for C++, Coplien (excellent description
of commonality/variability analysis -- I even recommend the first part for
Java programmers. See http://www.netobjectives.com/download/CoplienThesis.pdf for the
books equivalent on the web)
– Refactoring: Improving the Design of Existing Code,
Fowler

1/16/2002 Copyright © 2001, Net Objectives 175

 Net Objectives - Who We Are
• We provide training, mentoring and consulting for all phases of
object-oriented software development.
• We assist companies transitioning to object-oriented
development by providing mentoring throughout the entire
development process.
• This enables our clients a cost-effective way to gain experience.
• We offer courses in XP, Agile Development, Java, OOA, OOD,
Design Patterns, XML, XSLT, Schema, .NET, the Software
Development Process, and the UML
• To subscribe to our e-zine, send an e-mail to
info@netobjectives.com with “subscribe” in the subject line

1/16/2002 Copyright © 2001, Net Objectives 176

 Design Pattern Community of Practice
• This community of practice centers on the way Net
Objectives suggests using design patterns. A
description of this approach is in Alan Shalloway and
Jim Trott's Design Patterns Explained: A New
Perspective on Object-Oriented Design. This site,
and its corresponding discussion group, help facilitate
understanding of the book as well as providing
developers with a place to continue learning about
design patterns. As a development community, it is
comprised of developers who are committed to
honing their development skills and see that design
patterns can be useful in doing that.
• Go to www.netobjectives.com/dpexplained.htm for
more info.
1/16/2002 Copyright © 2001, Net Objectives 177
 Agile Patterns and XML
Communities of Practice
• The Agile Patterns community of practice centers on the
way Net Objectives suggests managing software projects.
Agile Patterns is a collection of best practices that is
loosely based on eXtreme Programming. However, we
have altered it in many ways, primarily in the areas of
documentation, design, and paired programming.
• go to www.netobjectives.com/lpa for more info.

• The XML community of practice centers on how to use

XML as a developer. It is different from most discussion
groups in that we have experts "lurking" on it to answer
your questions. It also is a forum to discuss and get
questions answered about Scott Bain's Introduction to
XML CD-ROM.
• go to www.netobjectives.com/xml for more info.

1/16/2002 Copyright © 2001, Net Objectives 178

 Future Presentations in Puget Sound
by Net Objectives:
• Free seminar on Refactoring, Design Patterns and XP,
Jan 30
• An Introduction to Agile Development, Jan 29.
• Design Patterns Explained, Feb 13
• Pattern Oriented Design: Design Patterns From
Analysis to Implementation, Mar 4-5
• Introduction to XML and Its Family of Technologies,
Mar 11-12
• Design Patterns Applied with Bruce Eckel, Apr 29-
May 3
For detail and Registration, see our Public Course
Schedule: http://www.netobjectives.com/pc_dps.htm
1/16/2002 Copyright © 2001, Net Objectives 179