MANAGEMENT S ROLE 1/16/2002 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 153
Metrics Tracking Risk mitigation Coaching Intervention Management Strategy 1/16/2002 154
Management Strategy Metrics Must measure estimates Must measure efforts Must measure results Else can t know what is going on! 1/16/2002 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 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 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 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 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 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 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 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 163
Management Strategy: Risk Mitigation Risks should be tracked. Resources are limited, worst risks analyzed and dealt with. 1/16/2002 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 179