Agile Development & Business Goals

Transcription

1 Agile Development & Business Goals

2 About the Authors Bill Holtsnider is an experienced writer, educator, and software professional with more than 26 years of experience working in the computer industry. His IT expertise includes working in such diverse areas as stock portfolio management, identity management, and software development. He is the author of six books and a wide range of technical and marketing documentation. Tom Wheeler has a long track record of building organizations to develop commercial software, including products for financial services and contact centers. He has built, sold, and been a senior manager in a variety of different types of companies, including international conglomerates and garage-sized start-ups. He first created the Six Week Solution back in the 1980s and has been fine-tuning it ever since. George Stragand is a manager and software developer with over 20 years of producing and managing the delivery of commercial software on time. He has worked for companies ranging in size from start-ups to multinationals, creating software for both external and in-house use. He still hasn t found a problem that couldn t be solved by one more level of indirection or a suitable amount of explosives in the correct location. Joseph Gee has spent the last 10 years of his career leading and coaching teams through a variety of successful projects and Agile transitions. His advocacy for software craftsmanship has equipped teams for success in small custom shops, large telecom enterprise systems, commercial shrink-wrap modeling software, and, most recently, cutting-edge behavioral analytics.

3 Agile Development & Business Goals The Six Week Solution Bill Holtsnider Tom Wheeler George Stragand Joseph Gee AMSTERDAM BOSTON HEIDELBERG LONDON NEW YORK OXFORD PARIS SAN DIEGO SAN FRANCISCO SINGAPORE SYDNEY TOKYO Morgan Kaufmann Publishers is an imprint of Elsevier

4 Morgan Kaufmann Publishers is an imprint of Elsevier. 30 Corporate Drive, Suite 400, Burlington, MA 01803, USA This book is printed on acid-free paper. # 2010 Bill Holtsnider, Tom Wheeler, George Stragand, and Joseph Gee. Published by Elsevier, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practices in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods, professional practices, or medical treatment may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information, methods, compounds, or experiments described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility. To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein. Library of Congress Cataloging-in-Publication Data Agile development and business goals : the six week solution / by Bill Holtsnider... [et al.]. p. cm. ISBN Management information systems. 2. Business Computer programs. 3. Agile software development. I. Holtsnider, Bill, 1956-HD A dc British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library. ISBN: For information on all Morgan Kaufmann publications, visit our Web site at or Printed in the United States of America

5 For J: Your dedication to others is awe-inspiring. B.H. For the Bills : One made the whole plan possible; the other got the story told. T.W. For the other Geordie for the tools, and Nick for the first chance to use them. G.S. For Mom and Don: Thanks for teaching me the importance of doing a job right. J.G.

6

7 Brief Table of Contents Preface... xiii CHAPTER 1 Introduction: Ask Yourself These 10 Key Questions... 1 CHAPTER 2 The Problem: Why Software Projects Fail CHAPTER 3 Expectations: What It Means for Software to Succeed CHAPTER 4 Overview of the Six Week Solution CHAPTER 5 The Solution s Critical Pieces CHAPTER 6 Managing the Cost of Change CHAPTER 7 Assuring Software Quality CHAPTER 8 Integrating Automation into Your Development Process CHAPTER 9 Other Software Development Approaches CHAPTER 10 Risks with Using This Approach CHAPTER 11 Transitioning to the Six Week Solution CHAPTER 12 Conclusions Glossary Sources vii

8

9 Complete Contents Preface... Who Is This Book Written For?... Chapter Summary... Acknowledgments... xiii xiii xiv xvi CHAPTER 1 Introduction: Ask Yourself These 10 Key Questions... 1 Introduction... 2 Ten Questions to Ask about Your Software Development Process... 2 Why Listen to us?... 7 CHAPTER 2 The Problem: Why Software Projects Fail Introduction Historical Perspective The Scope of Software Software Development Often Fails The Need for Process A Common Question Software Development Is Hard Very Hard Why Other Agile Methodologies Often Fail Why Waterfall Processes Often Fail High Visibility Death March Man in a Room The Rogue Developer Are You Done Yet? Budget Black Hole Why the Six Week Solution Is Different CHAPTER 3 Expectations: What It Means for Software to Succeed Introduction Software Development Sometimes (Accidentally) Succeeds Is Aligned with Business Needs Manages the Cost of Change Is Built in an Automated Way Factors Quality into the Core of the Process Is Not Constantly Being Redeployed Progress Is Constantly Being Made Delivers Something of Value ix

10 x Complete Contents Is Evangelical Is Predictable Is Both Tactical and Strategic Is Game Changing Allows Management to Stay Informed Is Measurable CHAPTER 4 Overview of the Six Week Solution Introduction Additional Problems Components of Agile Alignment Why Six Weeks? Cycle Commitments Developer Compensation: COD Six Week Iterations Time Boxing Development: Key Deadlines Week 1: Cycle Kickoff Week 3: Mea Culpa Week 6: Testing Steering with Business Goals CHAPTER 5 The Solution s Critical Pieces Introduction The Big Game The Entire Company Must Buy In Work Space Personnel Roles Hiring Smart Compensation Development Tools Cycle Commitments CHAPTER 6 Managing the Cost of Change Introduction Flattening the Curve with Feedback Loops Avoiding the Curve by Managing the Unknown Lowering the Curve by Increasing Productivity Providing Effective Tools Languages and Tooling Buy, Don t Build

11 Complete Contents xi Effective Communication Gauging Performance with Pairs CHAPTER 7 Assuring Software Quality Introduction The Value of Quality External Software Quality Internal Software Quality Symptoms of Design Rot Quality and Software Craftsmanship Size of Work Pieces Unit Testing CHAPTER 8 Integrating Automation into Your Development Process Introduction Continuous Integration Build Process Metrics Automation Tools CHAPTER 9 Other Software Development Approaches Introduction Simplified Evolution of Software Processes CHAPTER 10 Risks with Using This Approach Introduction Workplace Challenges Work Environment Why This Is Not a Risk Risk: Abandoning Quality for Bonuses Management Challenges Quality Concerns Design Debt Hard to Transition Smaller but Still Potentially Problematic Risks CHAPTER 11 Transitioning to the Six Week Solution Introduction Before You Do Anything, Though Automate the Build Selling This Idea up the Chain Selling It to Sales and Marketing

12 xii Complete Contents Determine Your Aggressiveness on Cycles and Compensation Set Expectations from the Start Pick the Date for the Cutover Use the Language of the Process Transitioning the Development Team Creating the Baseline Your First Six Week Cycle CHAPTER 12 Conclusions Introduction Aligns Software Development with Business Needs Developers Are Compensated Based on Their Performance Addresses Both Core Business and Core Technical Components Simple to Describe to Everyone in the Company Designed from the Ground Up to Produce Revenue-Generating Software Ties Directly into Your Investment in Your Software Development Accounts Directly for Quality Allows You to Hit Your Short-Term Goals While Addressing Your Long-Term Goals at the Same Time Rewards Success and Penalizes Failure What to Do Next Glossary Sources

13 Preface This is a book about a powerful type of software development an approach we call the Six Week Solution. WHO IS THIS BOOK WRITTEN FOR? Types of Individuals This book is for CEOs to give to their COOs and CTOs. This book is for CTOs to give to their software development managers. This book is for software development managers to use. They are the ones who have to make the software work: they have to build the teams, define the roles, buy the tools, and get the software written and up and running. They gotta make it all fly. They are the ones we really wrote this book for. Types of Development Teams We have two key audiences in mind: Start-ups putting a software development team in place for the first time. (You are greenfielding it.) Internal software development teams with established development methodologies delivering updates to an internal or external product. Start-Ups If you are greenfielding it, there are many important things you must do. This book is not written to cover all of the issues you will face, but it is written to help you design, implement, and manage a state-of-the-art method of creating world-class software. If you have not yet started building your team, we suggest you read the chapters mostly in the order in which they are written. Specifically, read Chapters Then, when you are ready to adopt the Six Week Solution, read Chapter 11, Transitioning to the Six Week Solution. Internal Software Development Groups If you are running a classic internal development team and you are reading this book, you are looking for a better way of doing what you are currently doing. This process is just what you are looking for. If you already have a team(s) working, you can read the chapters in any order you want and only the ones you feel are most appropriate for your organization. As a side note, if you are an internal software development team, software industry wisdom says act like a start-up. Do the same things start-ups do. While there are important differences between a xiii

14 xiv Preface start-up development team and an internal one, in some keys ways they are very much the same. When building teams and attracting talent, for example, the developers who thrive in a start-up environment are often (although not always) the types of programmers you will need to make a dynamic process like this work. CHAPTER SUMMARY Chapter Chapter One: Introduction Chapter Two: The Problem Chapter Three: Expectations Chapter Four: Overview of the Six-Week Solution Description The Six Week Solution is a unique and powerful process of creating software. To determine if this process is right for you, ask yourself the following questions about your current method of creating software. Does it: 1. Align software development with business needs? 2. Compensate your development team based on delivering on their commitments? 3. Have both Business and Technical components? 4. Lend itself to a description so simple that everyone in the company can understand it? 5. Produce revenue-generating results that address real-world needs? 6. Tie your investment in your software development to the delivery of the software you need? 7. Account directly for Quality? 8. Hit Your Short-Term Goals While - 9. Addressing Your Long-Term Goals at the Same Time? 10. Reward success and make the effects of failure tangible? This chapter discusses why developing software is difficult, much more difficult than it appears and more difficult than many other complex undertakings. Through this chapter (and the entire book, for that matter), we compare getting workable, useful software out the door to other demanding challenges; we do so in order to learn (and have you learn along with us), to get some perspective on the challenge we are facing, and thereby to better execute on the task ahead of us. It is no secret that software is often released late, in less-than-ideal conditions, and way over budget. This chapter discusses briefly how software used to be done. Specifically, we talk about how software development often fails, it sometimes (accidentally) succeeds, and is seldom aligned with business needs. We talk about why waterfall processes often fail, why other Agile methodologies often fail, that they don t manage the cost of change, and they don t factor quality into the core of the process. We discuss how to ship software in a timely manner, align your company with business and ship at least quarterly, and automate the build process. We discuss why six weeks was chosen as the length of the cycle, as well as what the key deadlines are in the process. Continued

15 Preface xv Chapter Chapter Five: The Solution s Critical Pieces Chapter Six: Managing the Cost of Change Chapter Seven: Assuring Software Quality Chapter Eight: Integrating Automation into Your Development Process Chapter Nine: Other Software Development Approaches Chapter Ten: Risks with Using This Approach Chapter Eleven: Transitioning to the Six Week Solution Chapter Twelve: Conclusions Description The Six Week Solution has the following critical pieces that are discussed in this chapter: the entire company must buy into the idea, work space, personnel roles, hiring smart, compensation, development tools, and cycle commitments. This chapter outlines strategies on how to tame the exponentially growing cost of the change curve and maximize the return on your investment of your software project. Software that functions as it should, every time, in every situation, is boring (and, of course, unheard of). At the same time, some people might use the term reliable for software that functions every time. But that turns out to be exactly what everyone wants: software so boring and reliable you don t think about it. This chapter describes tools, techniques, and methods for making sure you focus on the quality of your software. Much software in the 21st century is still built, reviewed, and tested manually. Tools and techniques exist now to automate almost every step of the software development process. Automating these steps can radically enhance not only the quality of your end result, but have a measurable effect on your bottom line. Read this chapter for details. In this chapter, the Six Week Solution is compared not only to the classic approach to software development ( waterfall ), but also to various flavors of Agile. No method for developing software is fool-proof, and no process exists without some risks. The Six Week Solution is no exception. This chapter discusses the following: small risks; large risks; things that appear to be risks but actually are not; and things that do not appear to be risks, but are actually potential landmines. We also provide methods of mitigating these risks. As you may know by now, the Six Week Solution is a unique approach. Transitioning from your current approach to this one will involve some specific actions, but we promise that the initial pain of the transition will be well worth it. This chapter discusses some of the common challenges we have seen companies face when making this changeover. This chapter discusses the benefits the Six Week Solution offers: Aligns Software Development with Business Needs Developers Are Compensated Based on Their Performance Addresses Both Core Business and Core Technical Components Simple to Describe to Everyone in the Company Designed from the Ground Up to Produce Revenue-Generating Software Ties Directly into Your Investment in Your Software Development Accounts Directly for Quality Allows You to Hit Your Short-Term Goals While Addressing Your- Long-Term Goals at the Same Time Rewards Success and Penalizes Failure What to Do Next

16 xvi Preface ACKNOWLEDGMENTS As we note in the book, the four us have nearly a century of combined years of corporate experience. Along the way, we have been fortunate enough to meet some exceptional individuals who have helped us significantly both professionally and personally. They have mentored us, supported us, and generally kept us on the Path. Without those very special people, we would not be where we are now and we certainly could not have written this book. To them we owe our undying gratitude. Reviewers We would like to thank the following individuals who helped review our book at its various stages: Peter Gallanis (Chief Architect and Co-Founder, Aha! Software), Robin George (Vice President of Engineering and Chief Architect, AIMCO), Bruce Bacon (Vice President of Product Strategy and Management, Aha! Software), Steve Ropa (Agile Consultant, VersionOne), Prashant Natarajan, Cameron Skinner (Product Unit Manager, Microsoft), and Bill Wood (Vice President, Product Development, Ping Identity). Graphics We want to thank Erick Stragand (estragand.com) for his excellent drafts of the cover art. But we especially want to express our gratitude to Tish Gance for taking time away from painting original automotive artwork at ferrarti.com to create our compelling chapter graphics this technical book is much friendlier and warmer because of her efforts. People at MKP We would also like to thank the people at the publishing team: Acquisitions Editor Greg Chalson, Assistant Editor Heather Scherer, Production Editor André A. Cuello, and copy editor Melissa Revell. Families Most importantly, we are tremendously indebted to our family and friends for their support and understanding during the difficult period that this book was being written.