MANAGEMENT S ROLE 1/16/ Copyright 2001, Net Objectives

Transcription

1 MANAGEMENT S ROLE 1/16/

2 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/

3 Metrics Tracking Risk mitigation Coaching Intervention Management Strategy 1/16/

4 Management Strategy Metrics Must measure estimates Must measure efforts Must measure results Else can t know what is going on! 1/16/

5 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, 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/

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

7 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/

8 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/

9 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/

10 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/

11 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/

12 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/

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

14 Management Strategy: Constraint List Must also maintain a list of constraints. Not management s role to find contraints -- just to maintain it. 1/16/

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

16 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/

17 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/

18 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/

19 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/

20 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 Chapter 5 Learning to Drive, pg 27 Chapter 10 A Quick Overview The Planning Game, pg 55 Refactoring, pg Hour Week, pg 60 Chapter 12 Management Strategy, pgs Chapter 14 Splitting Business and Technical Responsibility, pgs Chapter 15 Planning Strategy, pgs /16/

21 Bibliography - Web Resources - Net Objectives main site -- Net Objectives XP site Jim Highsmith, Cutter Consortium, Extreme Programming Scott Ambler - Agile Modeling Home Page 1/16/

22 Bibliography - Common Lightweight Methodologies Extreme Programming (XP) Adaptive Software Development SCRUM Crytal Clear Alistair Cockburn s web-site ( Feature Driven Development Java Modeling in Color with UML, Peter Coad Agile Alliance 1/16/

23 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/

24 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 for the books equivalent on the web) Refactoring: Improving the Design of Existing Code, Fowler 1/16/

25 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 to info@netobjectives.com with subscribe in the subject line 1/16/

26 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 for more info. 1/16/

27 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 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 for more info. 1/16/

28 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 Design Patterns Applied with Bruce Eckel, Apr 29- May 3 For detail and Registration, see our Public Course Schedule: 1/16/