elements of agile style ver 0.25agileconsortium.pbworks.com/f/elements of agile style ver... ·...

Elements of Agile Style ver 0.25.doc 1 of 72 4/12/2007 copyright 2007 Joseph Little

The Elements of Agile Style A handbook of reminders By Joseph Little Based on the work of Ken Schwaber, Jeff Sutherland, Kent Beck and others. Version 0.25

1 This is a DRAFT document. It should be published soon. Your comments and suggestions are welcome: [email protected] A PDF of this document is here: http://agileconsortium.pbwiki.com/The%20Elements%20of%20Agile%20Style\ Agile & Business blog: http://agileconsortium.blogspot.com/ Kitty Hawk Consulting: http://www.kittyhawkconsulting.com/

1 http://www.andrewmcknight.net/0609.html Permission sought from Andrew McKnight.

mailto:[email protected]

http://agileconsortium.pbwiki.com/The%20Elements%20of%20Agile%20Style

http://agileconsortium.blogspot.com/

http://www.kittyhawkconsulting.com/

http://www.andrewmcknight.net/0609.html


Table of Contents Preface.................................................................................................................................................... 4

WHAT THIS BOOK INTENDS TO BE........................................................................................................... 4 WHAT THIS BOOK IS NOT ....................................................................................................................... 4 WHO SHOULD READ THIS ....................................................................................................................... 5 A SMALL APOLOGY ............................................................................................................................... 5

Layout of the book ................................................................................................................................. 7 Where to start ........................................................................................................................................8

IS AGILE ABOUT VALUES AND PRINCIPLES OR ABOUT PRACTICES?.......................................................... 8 WHY START WITH SCRUM? .................................................................................................................... 8 WHY "THE RULES OF SCRUM"?.............................................................................................................. 8

The Rules of Scrum.............................................................................................................................. 10 THE ROLES IN SCRUM.......................................................................................................................... 10 THE ARTIFACTS OF SCRUM .................................................................................................................. 12 CHANGING THE RULES OF SCRUM ........................................................................................................ 14 GENERAL RULES ................................................................................................................................. 15 THE KEY EVENTS IN SCRUM ................................................................................................................ 16 SPRINT PLANNING MEETING ................................................................................................................ 17 DAILY SCRUM MEETING ...................................................................................................................... 20 THE SPRINT ........................................................................................................................................ 23 SPRINT REVIEW MEETING ................................................................................................................... 24 SPRINT RETROSPECTIVE ...................................................................................................................... 26

Standard Approach......................................................................................................................... 26 Alternative Approaches................................................................................................................... 27

GENERAL RULES ................................................................................................................................. 28 THE STORY OF THE CHICKEN AND THE PIG ........................................................................................... 29 USEFUL TO DEMONIZE? ...................................................................................................................... 29

Extreme Programming........................................................................................................................30 NOTE ON THE IMPERATIVE MOOD ........................................................................................................ 30

Values ...................................................................................................................................................30 HUMANITY ......................................................................................................................................... 30 COMMUNICATION................................................................................................................................ 31 SIMPLICITY ......................................................................................................................................... 31 FEEDBACK .......................................................................................................................................... 32 COURAGE ........................................................................................................................................... 32 RESPECT ............................................................................................................................................. 32

Principles..............................................................................................................................................34 HUMANITY ......................................................................................................................................... 34 ECONOMICS ........................................................................................................................................ 34 MUTUAL BENEFIT ............................................................................................................................... 35 SELF-SIMILARITY ................................................................................................................................ 35 IMPROVEMENT .................................................................................................................................... 36 DIVERSITY .......................................................................................................................................... 36 REFLECTION ....................................................................................................................................... 36 FLOW ................................................................................................................................................. 37 OPPORTUNITY ..................................................................................................................................... 37 REDUNDANCY ..................................................................................................................................... 37 FAILURE ............................................................................................................................................. 37 QUALITY ............................................................................................................................................ 38 BABY STEPS........................................................................................................................................ 38 ACCEPTED RESPONSIBILITY ................................................................................................................. 38


Primary Practices.................................................................................................................................40 SIT TOGETHER .................................................................................................................................... 40 WHOLE TEAM ..................................................................................................................................... 40 INFORMATIVE WORKSPACE ................................................................................................................. 40 ENERGIZED WORK .............................................................................................................................. 41 PAIR PROGRAMMING ........................................................................................................................... 41 STORIES.............................................................................................................................................. 42 WEEKLY CYCLE.................................................................................................................................. 42 QUARTERLY CYCLE ............................................................................................................................ 43 SLACK ................................................................................................................................................ 43 TEN-MINUTE BUILD ............................................................................................................................ 44 CONTINUOUS INTEGRATION................................................................................................................. 44 TEST-FIRST PROGRAMMING................................................................................................................. 44 INCREMENTAL DESIGN ........................................................................................................................ 45 HOW DO WE START WITH XP?.............................................................................................................. 45 WHO DECIDES? ................................................................................................................................... 46

Corollary Practices............................................................................................................................... 47 REAL CUSTOMER INVOLVEMENT ......................................................................................................... 47 INCREMENTAL DEPLOYMENT............................................................................................................... 47 TEAM CONTINUITY ............................................................................................................................. 47 SHRINKING TEAMS .............................................................................................................................. 47 ROOT CAUSE ANALYSIS ...................................................................................................................... 48 SHARED CODE .................................................................................................................................... 48 CODE AND TESTS ................................................................................................................................ 48 SINGLE CODE BASE............................................................................................................................. 49 DAILY DEPLOYMENT........................................................................................................................... 49 NEGOTIATED SCOPE CONTRACT .......................................................................................................... 49 PAY-PER-USE ..................................................................................................................................... 50

A Few Things We Haven’t Talked About.............................................................................................51 Retrospectives...................................................................................................................................... 52 Business Value: What is it? What do we do about it?....................................................................... 53

WHAT IS IT?........................................................................................................................................ 53 WHAT DO WE DO ABOUT IT? ................................................................................................................ 55

On Agile Adherence.............................................................................................................................58 Some Agile Quotes............................................................................................................................... 59

NOTE ON HUMOR................................................................................................................................. 60 Agile Leadership ..................................................................................................................................62 The Agile Manifesto............................................................................................................................. 65 Principles behind the Agile Manifesto................................................................................................66 What is Agile? ...................................................................................................................................... 67 The Six Blind Men and the Elephant..................................................................................................68 Resources .............................................................................................................................................70


Preface I am most grateful to have been introduced to Agile. I have worked on Agile with some wonderful people at several clients. This is my way of returning the favor. And of helping distill the most important parts of Agile for myself and for others. Agile is a way of working with people. It accommodates to the fact that you are working for people and with people. The Team is typically together for the first time, probably doing a project it has never done before, that often no one has ever done before. A better way of working We have heard it said, "It is more blessed to give than to receive". Agile is a way of working through that seeming paradox. And yet you also get something back, because Agile is, for you, a better way of working. So, do not start thinking Agile is a great sacrifice. While change is painful, yet it is a change to a better and more joyful way of working. Or at least so say many who have made the journey. Agile delivers more business value. For the customers and the shareholders. About people Agile is about people. People have been called "darkly wise and rudely great". Indeed, Agile works well whichever side of Alexander Pope's views on man you take (or that happen to occur in your project). (See his Essay on Man.] Not a silver bullet methodology Agile is not a methodology. It is not so highfalutin. It is down-to-earth and practical. It is perhaps a set of working methods or approaches to work. Agile relies on the team (and forces the team) to do a lot of thinking for themselves. This is a particularly good thing, in part because you usually have a brand new team or it is doing something brand new. This is how they discover. Agile is not a silver bullet. It does not solve all your problems. It does not give you magical answers to all your questions. It does not instantly make people better than they really are. It requires a lot of hard work and decision-making. But it does help. And it will help you, if you let it.

What this book intends to be This is a handbook in the old sense. A book you keep at hand on a day-to-day basis, to remind you of the things you want to be doing each day. It will cover only the most essential things. It is for all practitioners of Agile. And, as you will see, I think almost all of us should be practitioners of Agile. So it is for my friends and my family. And for you. You are expected to select from these great suggestions to create your own Agile style. You will anyway; why not do so purposefully?

What this book is not This paper is not an introductory text on Agile or Scrum, Extreme Programming or any other topic. I would start with Ken Schwaber’s Agile Project Management with Scrum. And I would read Kent Beck’s Extreme Programming Explained: Embrace Change. If you have not read at least these, go buy them now. In the Resources section we have suggested other books. The


Resources section covers both introductory topics and some more advanced topics. To keep this book short, I have not explained why I or Agile have suggested everything that is here. A full explanation for one piece can be quite extensive, and often one practice serves many purposes. Send me your questions, and I will endeavor to answer. And ask others. A few have asked me to write a more personal view of Agile. While I am flattered at the request, it causes me to make clear that that is not the purpose of this handbook. The related purpose is to remind us of the basics, which are widely shared and agreed by experienced people in the Agile community.

Who should read this As just indicated, if you are just getting started with Agile, you probably should get an introductory text first. You are welcome to read this, but you need more. The key audience is people who have been doing Agile for a few months. Or people who want to remind themselves of the key “blocking and tackling” aspects of Agile. The purpose is to remind us all of the most basic things. The audience includes anyone involved in Agile. The Team, the customers, the Business side, the managers, the ScrumMaster or coach. Everyone. This book does not cover advanced topics, or certainly doesn’t cover them completely. For example, if you want to cover Agile Estimating and Planning, see Mike Cohn’s book in the Resources list. Or see Derby & Larsen on Agile Retrospectives. Or Kent Beck on Test Driven Development. Or several others listed. This book is not trying to be a full guide to adoption of a new set of ideas and practices (eg, Agile). If you are looking for that, I would start with Fearless Change by Manns & Rising.

A small apology While I am often mistaken for a technologist (and perhaps there is some truth in that), I majored in English in college. While this helped me write better (I hope), it also led me to foist upon you allusions to literature you may not know yet (although I encourage you to read it).

* * * I trust that you, good reader, are doing good work, or else you likely would not be reading this book. Thank you for doing that good work. The world needs more like you.


Thanks and acknowledgements I, like every author, am grateful for the wrestle that this subject gave me. Surely not so successful as Jacob, nor so cunning as Odysseus, but I enjoyed it nonetheless for that. And for the forbearance of those who stood by me, with patience and comfort. Let me thank first my wife and my daughters. Let me thank my parents and my broader family, for having formed that better part of me. Let me thank the following for their thoughts and/or their support, which helped this book come to a life, such as it is. Many do not know what they have done, but it is valued perhaps even more because of that. Gene Garrett, Ken Schwaber, Jeff Sutherland, Kent Beck, Deb Hartmann, Michael Spayd, Jim York, Mike Vizdos, David Douglas, Robin Dymond, Mishkin Berteig, Tiffany Lentz, Kert Peterson, Michael Hamman, Barbara Wilders, Linda Cook, Roland Cuellar, Arlen Bankston, Mike Euripides, Michele Madore, Mark Pushinsky, Chris Doss, Kate VanBuren, Mary Poppendieck, Mike Cohn, Esther Derby, Diana Larsen, Jean Tabaka, Michael Feathers, Ron Jeffries, William Wake, Mary Lynn Manns, Ken Auer, Martine Devos, Doug Shimp, Stacia Broderick, Bob Schatz, Hubert Smits, Brent Barton, Mary Simone, Stephen Hailey, Prem Balagangadhar, Kim Witchey, Adam Beck, Kelly Snavely, Roney Pate, Tariq Bhatti, Mark Hugel, Ryan Scouller, Kara Silva, Ashish Govil, Dave Bittenbender, Darlene Schwartz, Jim Yu, Lee Patterson, Bill Lazo, Bill Dandridge, Diane Blanz, Martina Ruzickova, Michael Williams, Shane Hayes, Rick Lacher, Nancy Van Schooenderwoert, Jay Conne, Bob Louer, Janice Morrell, Stacey Edwards, Bob McNelis, Guy Beaver, Tom Finnie, Jason Sharpee, Jim Conrad, my friends at KPMG Consulting who first showed me agile, as I struggled blindly to find it, Bill Farris, Phil Heyl, Sakhr Tariki, Bill Ury, a friend or two now departed. Gosh, there are many others I would like to add. Let me also thank Ward Cunningham for the wiki, for Ward’s Wiki, and for his work in Agile. What is good belongs to them, what is bad is mine alone. May this book have only a portion of the merits of so great a group. That would be enough.


Layout of the book This book starts with the Rules of Scrum as a concrete basement. A foundation. The rules cover the main practices that Scrum defines. It is impressive and purposeful how spare Scrum proper really is. Having established a toe-hold on reality, we make an essay into the ethereal world of values and principles. Specifically, the values and principles of Extreme Programming as defined by Kent Beck. The practices, the values and the principles work together to show you how to use and modify and adjust Agile to fit you and your situation. Then we come back to the concrete, and discuss the primary and corollary practices of Extreme Programming. So many of these are now common-place that people assume they are a defined part of Scrum. Such is generally not the case. There are other practices than Scrum and XP, and in another version of this booklet we may discuss more. But I think Scrum + XP form a good set of practices for many projects, at least. In the last 15 pages of the book, we talk about some special topics: § Retrospectives, because they are so important in moving the Team forward § Business Value, because that’s what we do projects for (to release it) § Some Agile Quotes, which I will explain in a minute § Some comments from Jeff Sutherland about Leadership § The Agile Manifesto and Agile Principles, which define what Agile is § The story of the 6 Blind Men and the Elephant, because we always need Buddha’s

compassion. Finally, we suggest some additional resources. Why did we add the Agile Quotes? I describe myself as a recovering Waterfallic. This is meant to be a bit humorous. But also too true. We all find it hard to change our minds. So, the Agile Quotes by the famous Yogi are meant to be humor with a point. Humor with a lever that just might flip our brain lids, when other methods have failed. Do not laugh at humor. Besides, too many people are already too serious about too many topics. Now, let’s jump in.


Where to start There are two common ways to start any great subject. One can start in with the abstract and general ideas and become progressively more concrete. Or one can start with concrete things, and then infer the principles. We will deal with values, principles and practices (using Kent Beck's words), but we will start first with the rules of Scrum. Something relatively concrete. Two of the patterns behind this book are Just Enough and Step By Step.2 The idea is to start where you are, and add Jusy Enough to what you are doing to make a noticeable improvement. Don’t ask yourself or others to go too fast up the learning curve.

Is Agile about Values and Principles or about Practices? It is an age-old question about many subjects: Theory or Practice; the ideal or the concrete. My answer: Yes. To be adaptive, practitioners of Agile must examine their values and principles and use them to devise new or modified practices all the time. But Agile is decidedly not the mind-game of mere ideas and feelings. Agile sets out to help real people in need of real help. This requires specific, never-fully-perfected practices that are implemented today. Agile itself is not really important. What is important is that we work better; Agile is important because it helps us do that.

Why start with Scrum? Scrum sets in motion a simple empirical process, from which the team can evolve to better practices and approaches in other areas. We would not fight a team that wanted to start with Extreme Programming and then add in Scrum. But we suggest that starting with Scrum is better in most cases.

Why "the Rules of Scrum"? The Rules are a simple way to summarize and make concrete what Scrum is. Scrum seems simple, but indeed what is going on is quite complex. I invite you to imagine and grasp the purpose or purposes behind each rule. In some cases these purposes are discussed a bit. But frankly, starting with the Rules gives me some trepidation. Rules are never an excuse to suspend thinking or stop using common sense. But if you break a rule, be sure you are wiser than, or a least in a different situation than, the ones who made the rules. We all know the personality types that like rules. And some of those people take great pleasure in

2 See Fearless Change by Manns & Rising.


enforcing rules on others. Quite frankly, encouraging those related attitudes is something I find particularly unhelpful for teams doing work they have never done before (ie, most projects). When most people start Scrum they are very busy unlearning old rules. Too much focus on rules may reinforce them in thinking, "the rules will make me safe", rather than thinking for themselves "what are the best and most essential things to do to bring this project to success?" Following the rules will generally be helpful, but they are no real protection from thinking and dealing with all the issues that will come up in your project. It is no excuse to say, “I followed the rules, so I’m not responsible if the project fails.” The Team does need a minimal set of rules. It does not need one person (such as a "command and control" project manager) to rigorously enforce a large set of rules.


The Rules of Scrum This section largely paraphrases what Ken Schwaber has expressed better and more thoroughly, most notably in his latest book, Agile Project Management with Scrum (2004). Perhaps expressing it a different way will open a few more ears. Perhaps more usefully, these are reminders. Things that you can work on, step-by-step. Again, buy and read Ken Schwaber’s book. Or read it again.

The Roles in Scrum Scrum has three roles: the Product Owner, the ScrumMaster and the Team. And we might also include another role: Stakeholder. We will not attempt a full description of these roles. This is partly because each actor always makes something different of the role he plays than the actor before him. Ethan Hawke's Hamlet will be a bit different than Sir Laurence Olivier's Hamlet. The Product Owner decides what the project is about, and decides the priority of things that the project team will work on. And the Product Owner decides when the project is done. This includes determining when the conditions of satisfaction have been met, and when it no longer makes business sense to continue to invest in the team on this project effort. The ScrumMaster leads the Scrum process, and is that independent person who tries to optimize the productivity of the whole team (including the Product Owner). So, as there is usually tension between the Business side and the Technology side, he helps balance that tension. The ScrumMaster is meant to play the position with minimal external authority, partly so that the SM does not become the new name for a taskmaster project manager. So I will not endue the role with any extra authority. The ScrumMaster’s key role is removing (or helping to remove) the biggest impediments for the Team, and the Team’s lack of knowledge about how Scrum works is usually that first impediment. The Team is that group of people who, like the musketeers, have banded together to Git-R-Done3 for the project. Hopefully they have the attitude of "all for one and one for all", but that is not essential at the beginning. The ScrumMaster is not a member of the Team, but the Product Owner is (although a special member). Using a basketball metaphor, the ScrumMaster coaches from the sidelines, while the Team actually plays the game. The Stakeholders have a role in Scrum, especially in reviewing the work that the Team has accomplished. Sometimes they are chickens (see the story of the Chicken and the Pig), but this is a very simplified view. Whether a stakeholder is as motivated or not, he may still be quite useful. “Stakeholder” covers a wide range of types of people. It includes the project sponsor and her managers. Stakeholders may include users or customers of the system, typical staff functions (risk, compliance, legal, etc), or other areas (eg, the product belongs to the marketing folks, but the operations folks also must use it). Stakeholder also includes the managers of the Team. So, blanket statements about stakeholders are hard to make. If the stakeholders are misaligned (eg, have different goals than the Product Owner), the Product

3 Cultural Note: Git-R-Done is a saying of Larry the Cable Guy (Blue Collar Comedy), meaning “get her (or it) done”, presumably without using the best manners.


Owner needs to resolve that mis-alignment. Experience has shown that most stakeholders make useful contributions to the project from time to time. It is common for stakeholders not to feel the same urgency that the Team will feel, as one would well expect. This is not a stakeholder’s fault, but a fact of life that must be addressed. Some stakeholders may be used to directing the Team in what they will do, in a command-and-control style. This situation is typically quite troubling. Often it sucks a lot of energy and ownership from the Team. Some obvious advice about the Team: Get the best people you possibly can to be Team Members (and to be the Product Owner). There is no substitute for really good people who want to do the work. People are remarkably good at what they want to do. This is encoded for us in "where there is a will, there is a way". First, do not detract from their long-term motivation.4 Then, try to help them increase their own motivation (Agile will help).

4 The similarity to the “First do no harm” idea is intended.


The artifacts of Scrum Scrum focuses the Team on several key artifacts or outputs. There are other outputs, but the following are the artifacts that are most important in Scrum. Background - First, you need to know that an Iteration or Sprint is a fixed time span, usually one to four weeks. Ken Schwaber strongly recommends one-month sprints. Mike Cohn typically goes with 2 week Sprints. My experience is that teams new to Scrum (and they remain new to Scrum for some time) do better with 2 week Sprints. Additional factors can also influence iteration length. Arguments for a one-month Sprint. It is a common cycle in many companies. In that period a Team can generate enough functionality to have significant interest to the Product Owner and stakeholders, so that more stakeholders will attend Sprint Review Meetings. Teams are less likely to complain that it is “insufficient time to get anything done.” Arguments for a 2-week Sprint. Most beginning teams can almost feel their way to the tasks they can do in 2 weeks; it feels tight. To them, a month feels loose, it feels like a long time, and they can’t estimate quickly in their head when that timebox is “full”. The Team gets to inspect-and-adapt twice as often, so more corrections can be made sooner. The Product Owner sees increments more frequently, so he can determine more often whether the Team and the project are on target. And the Product Owner can learn more frequently about what it is he really wants (or his customers really want). While some Teams cannot get a small software package done in the first Sprint or two (and are almost surely going to complain about this at first), they soon can and the complaints dissipate. If senior stakeholders cannot come to a Sprint Review meeting every 2 weeks, have them come to one every other time (ie, about once per month). Product Vision & Business Case - The Product Owner must articulate the vision of what the project is all about, and how that makes business sense. Assuming you are doing the project in the context of a for-profit business, there must be a good product vision, and a result that its customers will appreciate. And usually appreciate it so well, that they will pay for it enough to enable the firm to compensate everyone, including its shareholders, handsomely. The Product Owner has that difficult task of convincingly explaining where the business value is hidden. And being right. Obvious advice: If the basic idea of the project is not very clever or won't make money for the firm in a reasonable ratio to the cost, then good people are not going to be satisfied after working on the project, no matter how "successful" the project itself was. Make sure you have a good product vision and a good business case. Product Backlog - This is the list of large chunks of work that the Product Owner wants done. One might call many of these things business requirements. (They are more likely to be high-level business requirements than low-level user requirements.) The Product Backlog comprises all the known work the Team must do to complete the project. The Product Owner owns this list, and re-prioritizes it each Sprint. Sprint Backlog - The Product Owner and the Team take several items from the Product Backlog, and convert them into tasks for the current Sprint (or iteration). So the Sprint Backlog includes those Product Backlog items plus the associated tasks (ie, the tasks to complete a given Product Backlog item). The Tasks have been estimated for effort (eg, hours), and probably include the performer. The Team owns and updates this Sprint Backlog during the Sprint.


Blocks List - This is a list of all the Blocks or impediments that are slowing the Team's productivity. The items can come from many places. The ScrumMaster owns this list, prioritizes it and assures that someone (perhaps himself) is working on each of the highest priority items. Increment - If the team is producing software, then the increment is the potentially shippable software that it produces at the end of each Sprint. If the Team is producing something else, then the increment is that part of the final product that best allows them (with the Product Owner) to inspect and adapt. It is OK if the increment for a few Sprints is not exactly what the Product Owner wanted, so long as the Team learns quickly from this experience (eg, why they mis-communicated) and they get the Product corrected.


Changing the rules of Scrum Many people want to change the rules of Scrum. In general, we take a dim view on these changes. Scrum is so simple and bare, that there is hardly anything to modify. At least usefully. (There are many, many additional “things” to add, but this is discussed later.) If a ScrumMaster and Team have some real experience with Agile, and still think they want to modify Scrum, go ahead. But be cautioned. Most of the minimal things that are there have been put there for your protection. The ScrumMaster should only let the Team consider a change if he feels they have some real understanding of agile and Scrum. Then, the change should only be made after discussion with the full Team and, and probably not unless almost all think it's a good idea. Adding to Scrum is a different thing. In some sense, every Team and every Project definitely requires "doing some stuff" more than Scrum. But that stuff is not Scrum itself, and it should only be added for that specific project. When you start the next project, start only with the bare bones of Scrum. In that sense, Scrum is just the beginning. If the addition is only for one project, and there are some members of the Team who will question why anything needs to be added (since it might well hurt more than it helps), then go ahead and add if the Team basically agrees. Just don't call those added things part of Scrum. Say, "...and the Team has these practices in addition to Scrum." We are uncomfortable if the additional "rules" are felt to be useful for "all projects". This strikes us as a likely backdoor to getting back to waterfall, with lots of rules and formality, and precious little real work being done. We are very sympathetic but also cautious about additional "rules" that talk about common XP or Agile practices such as a collocated team5, a team room, information radiators, and some of the other primary XP practices. We like all these practices. But, as Kent Beck has noted, people will not reach their creative potential if they feel they are being forced to do things. Be very mindful of the motivational impact of adding "rules." If you are one who is "making rules", it may be more useful to say, "If you follow this minimal standard of Agile, I will give you more support than if you completely invent your own, probably sloppy, version of Agile". Rewarding good behavior is probably more useful than punishing "bad" behavior. Almost all change feels painful at first, so we do need to give people an incentive to change.

5 Collocation is defined where we discuss the Sit Together practice.


General Rules Team Size: Teams should be 7 people, plus or minus 2. Again, the Product Owner is part of the Team. Larger groups should be sub-divided into 2 or more Teams. Scrum includes the "Scrum of Scrums" approach6 to dealing with larger, somewhat interdependent projects or programs. Team Member Dedication: All Team members should be 100% allocation to one Team. There are many reasons for this, but focus and motivation are probably the top reasons. And these Teams are simply more effective. It is understood that circumstances may arise where this rule must be broken. But breaking the rules is always a Block and the ScrumMaster must make sure this Block (and its cost or risk) are quite visible to all the interested people. The ScrumMaster should assure that each person considers (and re-considers) the downsides of breaking this rule. Experience has shown that this rule is broken far more often than it should be. The parties involved always convince themselves “we have to”, but what is often most compelling is only their lack of understanding and their lack of will.

6 See Agile Project Management with Scrum in the Resources.


The Key Events in Scrum First, meetings in Scrum (or Agile generally) are not for boring monologues. They are best done as spirited group discussions, and kept relatively informal. And quite honest and direct, albeit respectful of each person and each person's contribution. We are not trying to have everything be a group discussion. This is one reason why the Scrum meetings are timeboxed. There are 4 key Scrum meetings: § Sprint Planning Meeting § Daily Scrum § Sprint Review Meeting § Sprint Retrospective

Let's talk about each meeting in turn. And we will also include the rules for the Sprint itself.


Sprint Planning Meeting Purpose: This meeting is to decide what the Team will be doing in the coming Sprint. You might tell recovering Waterfallics that this is where Scrum identifies the equivalent of a detailed project plan. Timebox: Ken Schwaber calls out a timebox of 8 hours for a month-long Sprint. Obviously, if the Sprint length is less than a month, the timebox should be proportionally less. Thus, a 2-week Sprint would be done within 4 hours. Ken Schwaber also calls out 2 smaller timeboxes within the 8 hours. A 4-hour segment to select the Product Backlog (or PB) items and another 4-hour segment to prepare the Sprint Backlog. Certainly for beginning teams, I have found the ability to keep these two activities separate is limited. Example: The Developers often think they understand a PB item in the first segment, but as they are doing tasking, they realize that they have more questions about it. So the segment timeboxes are not as rigid as they might appear at first to some. Attendees: The Team (including the Product Owner), and the ScrumMaster. Additional parties may be invited if they are useful to the Team. There is experience and concern that these other parties can be distracting “chickens”7, so include others with care. But clearly, if additional people can help the Team, they should be included as needed (eg, for only the part of the meeting where they are needed). Some Teams find it useful to include managers in part of the Sprint Planning Meeting rather than write status reports for them. Use with care. Preparation: The Product Owner (with others as needed) must prepare the Product Backlog before every Sprint Planning Meeting. If the Product Owner fails, the ScrumMaster must do this. (This means that the Scrum cycles continue, and an increment will be produced. And all parties can inspect this increment. Typically, the observation will be made that things would be better if the Product Owner had prepared the Product Backlog.) We usually learn during the Sprint, so this learning needs to be reflected in the Product Backlog. New stories are added, old stories are revised or deleted, priorities change, estimates change. This is Product Backlog refactoring. It is strongly recommended that before coming to the Sprint Planning Meeting, each PB item have two estimates: an estimate that reflects "why we want to do this item" and an estimate of relative effort (eg, an estimate in Story Points8). The prioritization of PB items is usually based on three things: business value, risk and effort (in other words, cost-benefit). First Segment: In the first segment, the Product Owner describes the Product Backlog items he wants the Team to do in the next Sprint, and the Team determines whether they can commit to completing all or many of those items. The Team can propose and explain why other priorities might be better, but ultimately the Product Owner determines the priorities. On the other hand, the Team determines how many PB items it can commit to. In this way, the power is balanced. By committing, the Team is saying it can produce potentially shippable product functionality related to these PB items. If the Team is building software, then it is potentially shippable 7 See the Story of the Chicken and the Pig, later. 8 A Story Point is a nebulous unit of effort, indexed to a standard sized story (or PB item). Thus, an item of 4 Story Points is roughly twice as big an item of 2 Story Points. See Mike Cohn’s Agile Estimating and Planning book.


software. If there is some limited degree to which the product is not fully shippable (eg, it will not be fully integration tested or it must go through standard Release Management steps), then the Team should make the additional effort very clear up-front to the Product Owner. More specifically, the commitment means the Team will demonstrate the product functionality to the Product Owner in the Sprint Review Meeting at the end of that Sprint. The segment timebox means that the Product Backlog selection can only be discussed so long. Once we select the PB items, then we have sufficient time to do the second segment. This limits analysis paralysis (further analysis can be performed during the Sprint). Product Owner: be aware that if the Team does not fully understand the PB items you explained, this may cause it to commit to complete PB items that it will not be able to complete. (Of course, there can be other reasons for not completing them.) Team: recognize that in most circumstances it is extremely helpful to you to develop a feeling of trust from the Product Owner, that he trusts that you will deliver almost everything you commit to. Do things to foster that trust. Build the trust; it will help you. Second Segment: Immediately the Team starts to take the PB items and break them down into tasks. Again, observe the overall timebox. Some teams want to "know everything" before they identify the tasks, and this desire, while good in limited doses, must be controlled. The Product Owner must be available to the rest of the Team in this second segment, to answer questions about the Product Backlog. It is also useful that the Product Owner confirm for himself that the tasks reflect the work needed to complete the PB items agreed to. While the PO can question or suggest tasks ("Don't you need to do X to complete that?"), he may not tell the Team its tasks. On the other hand, if the Product Owner's comments make sense, of course the Team is well advised to listen. The trick, of course, is to build a productive relationship between the Product Owner and the rest of the Team. What that means precisely and how it can be improved varies remarkably from situation to situation. For example, if the Product Owner asks questions that the Team views as veiled demands for specific tasks, then the ScrumMaster must tell the Product Owner he may not do that. It is important in many ways that the Team fully owns its tasks. Similarly, no one outside the Team should be a direct or veiled taskmaster to the Team. Indeed, no one person on the Team should dominate in identifying the tasks (such as a current or former Project Manager). Exactly when higher participation becomes domination can be one of the tougher calls for a ScrumMaster to make. Among the factors, the ScrumMaster must weigh how much the Team may be demotivated. As indicated earlier, the Team may solicit information and advice from others as it creates the task list. Sprint Backlog: The output from the second segment is the Sprint Backlog. This includes a list of all the tasks that will be done in the Sprint. Each task has an effort estimate and ideally only one person assigned to it. It is recommended that each task be no larger than one day’s work. In that way, you can declare that you are starting the task in one Daily Scrum, and celebrate completion in the next Daily Scrum (or ask for help). Completeness: Must the Sprint Backlog be absolutely complete (contain all tasks) at the end of


the Sprint Planning Meeting? No. Obviously the Team will learn during the Sprint, and often that learning will identify other or different tasks than what they identified in the Sprint Planning Meeting. This learning is normal. At the same time, the Team (together with the Product Owner) must be creative in figuring out how to complete all the committed PB items in the Sprint timebox. Thus, many things may change during the Sprint, such as the specific tasks, but the basic commitment to completing the key functionality embodied in the PB items does not change. The Rules: You should already observe that these Rules of Scrum do not explain every detail about how to do a Sprint Planning Meeting. May you discuss other topics in a Sprint Planning Meeting? Of course, if they are important enough. Must all attendees be collocated? Well, do you think it would help? How is the Product Backlog and Sprint Backlog instantiated physically? Cards? You decide. Think for yourself. The Team (in some collaborative way) has to invent the rest of the "stuff to do" to make sure your project will be successful. Use the spirit of Scrum and the spirit of Agile (from the best people you can find) as one guide in making those decisions and in taking those actions.


Daily Scrum meeting This is sometimes called the daily stand-up. It is recommended that all attendees stand-up during the meeting to promote brevity. The meeting is meant to be short, and only the most necessary things for the team are discussed. General Purpose: At a high level, Scrum wants all the people connected to the project to be successful. Use common-sense, and don’t mistake rules for common usage with inviolate rules that must be obeyed exactly in every circumstance. At the next level, the Daily Scrum is there to help the project make progress towards its largest goals. Think for yourself; you are never a mere captive of some arbitrary agenda. Specific Purpose: As a rule, the meeting has two purposes. For the Team to sync up, so that everyone has a quick overview of progress to date and current direction. For the Team to inspect and adapt, especially in the form of identifying and starting to deal with the key impediments to the work. Timebox: 15 minutes regardless of the number of Team members (and, with a team of 5 or more, it should not be completed in less than 5 minutes). What does this timebox mean? In simple terms, we answer the 3 questions and have a very limited amount of other discussion in that timebox. What if we need a longer discussion? Fine. Do it right after that timebox. Almost always the longer discussion is with a subset of the team. Timing: The Daily Scrum is best held first thing in the morning, so that the first thing Team members think about is: “What did I do yesterday? What will I do today?” This fits a natural human rhythm. Attendees: All Team members and the ScrumMaster are required to attend. Every day. Occasional absences of one person or another are not major concerns. More frequent absences (of one person or a combination of people) are typically an important impediment. If a Team member cannot attend in person, he should attend by phone or by having another Team member represent him (eg, answering the questions for them). This of course requires that those two people communicate before the Daily Scrum, and after. Promptness: It is very important that all Team members are on time for the Daily Scrum. The ScrumMaster starts the meeting on time, no matter who is in attendance. If a Team member is late, they pay $1 to the Team kitty immediately. Periodically, the Team kitty is used to buy donuts or similar treats for the Team. (The Team may devise other “incentives” for attendance at the Daily Scrum, once they appreciate the importance of the meeting.) Start: The ScrumMaster starts with a random person on the Team (perhaps the person to her left). And the speakers proceed in a clockwise or counter-clockwise manner until every Team member has spoken. The Questions: Each Team member should answer the 3 questions: What did I do yesterday? (Since the last Daily Scrum) What will I do today? (Until the next Daily Scrum)


What impedes me from performing as effectively as possible? Key: Address the most important facts or issues for the day. The 3 questions should help the Team do that most of the time. They keep each person focused. But having the 3 questions is no excuse for ignoring or not discussing something else that is very important. Discussion: Team members may, very briefly, discuss what a Team member has said, once he has said it. Such as: “Perhaps I can help, let’s talk afterward.” “Can I talk to you later about helping me?” “Can we talk afterward about X that you just mentioned?” One person should not dominate the discussion (for example, a Team member should not feel they are answerable to one person, such as the Project Manager). The conversation should normally be brisk. If some topics require more discussion, someone should request a conversation for after the Daily Scrum, even if the topic is important. Focus on the 3 questions; do not digress into issues, designs, problems, or gossip. When these other things are discussed later (say, that day) include everyone who is interested in that topic (usually not the whole team). One person talks at a time. Everyone listens carefully. No side conversations. This is partly because everyone is responsible for the whole delivery of the project, and everyone’s thinking about this is needed. Chickens don’t talk9: Stakeholders in attendance should not normally talk or be obtrusive during the Daily Scrum. They should stand on the periphery of the Daily Scrum group (not to be intrusive). Reminder: Stakeholder covers anyone who is not a team member, the PO or the SM. Potentially a very broad range of people. Why? Experience has shown that stakeholders, without intending so, often interrupt the natural flow of the Team, and impede its progress. The Team has important work to do in a 15 minute timebox during the Daily Scrum. This must not be impeded. If too many stakeholders want to attend a Daily Scrum, the ScrumMaster may limit their attendance so that the meeting is more useful for the Team. (In some circumstances, one extra person could be too many.) A stakeholder may talk to the Team after the Daily Scrum, so long as he is not impeding their progress. Discussions that the Team wants and initiates are certainly fine. Other brief conversations are typically not a problem (if a team member feels he hasn’t time today, he can certainly say so). The Team should not feel they must “report” to one or more stakeholders. The Team owns the project. This is an area where the ScrumMaster must err on the side of protecting the Team. But certainly most stakeholders are deserving of an explanation of where the project stands. Usually this can be done quickly by showing them the information radiators in the team room. Often there is difficulty early in a project, when the project is normally floundering a bit and testing several hypotheses, and a stakeholder (who is not used to this) comes in and becomes concerned. This stakeholder can be very disruptive. One of the ways to guard against this is for the Team to make and keep small promises; this built-up trust allows the stakeholder to be more patient.

9 See the Story of the Chicken and the Pig, later.


If any non-team member is ignoring these rules and impeding the team (as interpreted by the ScrumMaster), the ScrumMaster must bar them from the Daily Scrum.


The Sprint Timebox: Ken Schwaber calls for a Sprint length of 30 days, to conform with a standard rhythm in many firms. Others recommend a length of 1 to 4 weeks. As indicated earlier, I and others find that a 2-week iteration length is best for most new teams. Three week Sprints are discouraged, because they are longer than two weeks and don’t fit the natural monthly cycle in any way. It is typical for new Teams to feel they cannot produce potentially shippable software in the first 2 weeks (or often, even in the first month). This is sometimes correct (eg, the full development environment is not built yet), but often it is no more than a human fear. Purpose: The Sprint is that period of time during which the Team does all the work needed to deliver the Product Backlog items it promised in the Sprint Planning Meeting. Assistance: The Team may seek outside advice, assistance and help during the Sprint. (Of course, any costs may need to be approved.) Intrusion: No one may intrude on the Team, eg, to give it unsought “advice”, help or assistance. No Change to the PB Items Promised: No one may change the PB Items promised for that Sprint. Not the Team and not the Product Owner. There are two fudges to this. One is “even-swap” as discussed below. The other is “story negotiation”. By negotiation we mean that the Team and the Product Owner negotiate something less “difficult” but still within the meaning of the story. Abnormal Termination: If the Team sees that it cannot complete the Sprint (at all) or if the Product Owner wants to change priorities, the current Sprint should be terminated. Then a new Sprint Planning Meeting can happen immediately, and a new Sprint can begin. This of course means that most of the work of the current Sprint will be lost. The ScrumMaster may terminate a Sprint on his own, or may approve a termination at the request of the Team or the Product Owner. Underlying causes of abnormal termination include: external business conditions have changed, significant new priorities have just become known, the original technology chosen is not workable for this project, a stakeholder starts to interfere with the Team, etc. Other Variations: If the Team has not begun a PB item to be excluded, it may be acceptable to substitute another PB item of the same or smaller size and continue on with the Sprint. The ScrumMaster must approve this, and should take great care in allowing this to happen. Must a PB item be started and completed solely within a Sprint? There is no rule on this. It is strongly recommended that PB items be started and completed within a Sprint. And, related to that, that each PB item represent a whole piece of business value by itself. Still, various conditions (temporary or permanent) may make it necessary that the Team start one or two PB items that they do not fully complete within the same Sprint. The Team must make the parts that are not done visible to the Product Owner as soon as possible.


Sprint Review Meeting Set-up: The ScrumMaster should determine who should come to the meeting, invite them, and arrange a room that will accommodate the attendees. Attendees: All team members (including the Product Owner) and the ScrumMaster must come. Interested Stakeholders and other parties (eg, uses, customers, etc) may come. Timebox: 4 hours for a 30-day Sprint. 2 hours for a 2-week Sprint. Preparation: The Team should spend no more than 1 hour preparing for the Sprint Review Meeting. Purpose: For the Team to present to the Product Owner and Stakeholders the functionality that was done. What does Done mean? The meaning can vary from organization to organization. It is always a version of "potentially shippable software". And if there is a choice between less done or more done, a PB item should always be more done. It is always necessary that the Product Owner and the Stakeholders completely understand the meaning of "done". This should be repeated regularly, with the assumption that the first few times they hear it, they don't appreciate what it really means. No Presentation: Functionality that is not done may not be presented or demonstrated. (If promised functionality was not completed, the Team must make this clear to the PO.) How to deal with incompleteness in the next iteration? Create a thin slice of functionality that can be fully completed, even though the larger module may not get done. Of course, it must be clear to the PO how thin that PB item is. Artifacts are not a substitute for software: The Sprint Review Meeting is not a place to discuss artifacts such as a Requirements spec or a Design spec. Working software is the measure of progress and the basis for inspecting and adapting. (The Team may document requirements and design as much as makes real business sense along the way or afterward; but the Sprint Review meeting is not a place to review these kinds of documents.) Don't confuse the Product Owner: The Team may not use documents, Powerpoints, or other things that appear to show progress, or that may confuse the Product Owner and others. Again, working software is the measure of progress. Artifacts (such as documents) may be used as a supplement to help clarify progress to the Product Owner. Discussion: During the Sprint Review, the Team must discuss progress and how other factors are affecting their work. So, discussion is an integral art of the Sprint Review. Demonstration: Functionality should be demonstrated from a team member workstation or another workstation.10 Use an environment that is as close to the Production environment as possible. Usually this is the final Quality Assurance (QA) environment. Verbal Review: The Sprint Review starts with one or more Team members discussing the

10 I have a question here.


Sprint Goal, which PB items were promised, and which PB items were completed. And any key issues in completing the promised PB items (ex: "Once we showed the PO our first version of this PB item, the PO had some questions about it, so we did not complete it."). Any Team member (including the Product Owner) may mention key things learned during the Sprint (eg, new risks, new technical issues, key learnings about the functionality, new blocks, etc.) Demo Discussion: The majority of the time is spent giving a demo of the software and discussing the learnings. So, the Team members present the demo and answer questions from the Product Owner and other stakeholders about the functionality. Someone takes notes regarding desired changes to the system(s). Stakeholder Comments: The stakeholders are free to discuss the working software, eg, compliments, comments, observations, criticisms, etc. Note: At some point it should be made clear to the stakeholders that the whole Team, including the Product Owner, is responsible for the Sprint results, including both the good and the bad. Perhaps the ScrumMaster should make a quick reminder about this is at this time. Polling Stakeholders: At the end of the demo, the stakeholders are polled, one by one, to get their impressions, and specifically any desired changes after seeing the demo. And their sense of the priority of these changes. PO Decision: The Product Owner discusses any proposed changes, including any of his own, and discusses how he sees these changes affecting the Product Backlog. The Team members may also comment, and should comment on their sense of the relative effort of the new or changed PB items. They should also comment on the technical risk associated with these items. Ultimately the Product Owner must decide on the priority of these new or changed PB items. Next meeting: At the end of each Sprint Review, the SM announces the place and time of the next meeting.


Sprint Retrospective As implied by its positioning here, this meeting occurs after the Sprint and after the Sprint Review. You might think of the Sprint Review as reviewing the output itself, and the Retrospective gets at the team and how it does the work. Timebox: 3 hours for a 30-day sprint and 1.5 hours for a 2-week Sprint. We find that the time allotted to a given Retrospective can vary a lot, and it is often useful to vary it, depending on a lot of factors. The purpose is to keep it fresh, so that fresh action items come out. However, once the Timebox is set for a given Retrospective, it should be followed. Purpose: A retrospective can have a variety of specific purposes. The general purpose is to help the Team collect, analyze and decide on information that will help them get better. Typically a retrospective should lead to specific actions to improve the Team, the project, or the product. A retrospective may focus on an iteration, a release, a project or some other time period. A retrospective may cover all the activities of the Team or focus on a sub-set of those activities, such as one of the key meetings or an engineering practice. The retrospective is not meant to be a mutual admiration society or a bitching session, although these are normal human activities that will occur to some degree. While appreciations often lead to better discussions, great insights and better actions, the purpose of the meeting is not for appreciations per se. Attendees: The Team (including the Product Owner), and the ScrumMaster. With experience and great care, the ScrumMaster can decide to include or exclude specific people, if that will help the Team deal with useful issues.

Standard Approach Gather Information: In a typical Retrospective with a focus on all activities within one iteration, the standard approach is to start by having all attendees answer these 2 questions: what went well? (Plus) what could be improved in the next Sprint? (Delta) Early on, the SM often will need to ask that each person give at least one Plus and one Delta. (The SM uses this and other techniques with less-talkative team members.) Summarize: The SM will write down the Pluses and Deltas in summary form. Analyze & Prioritize: The Team discusses and prioritizes the items (issues) that it thinks could lead to the greatest improvements for the next iteration. The SM assures that the Blocks identified here are added to the Blocks List. Select Action Items: The Team identifies action items for the next iteration (ie, that will be taken during the next iteration, and that hopefully will have impact for the next iteration as well). Anyone appropriate may take the actions; as mentioned before, the ScrumMaster owns the Blocks List and owns managing the actions to remove impediments. Almost always, that also means the


ScrumMaster is taking some action herself to remove one or more impediments during the current Sprint. Keep focus; usually you don’t want to attack more than one or two Blocks at a time. Place Actions in Iteration Backlog: Actions of sufficient size should be placed in the Iteration Backlog under a high-priority nonfunctional PB item(s). NB. Retrospectives where no action is taken become sterile and frustrating. Facilitator: The SM is the organizer and facilitator of the meeting. With experience and care, the ScrumMaster may assist a Team member or an outside person (an SM for another team) in organizing and facilitating a Retrospective. Sometimes, just having the Retrospective lead by a different voice or personality can lead to new insights. No Domination: The ScrumMaster is not at the Retrospective to provide "solutions" to higher team productivity. The Team needs to think for itself. The Team must self-organize. With experience and care, the ScrumMaster might add a few comments or ideas after others have chipped in. If the Team independently thinks these things are priorities, then they can be pursued. Similarly, no other one person should dominate the Team's thinking about how it can improve. What is Action?: One type of person views action as something very concrete, such as implementing a new testing tool. And certainly it can be. Another type of person sees action more in terms of the people issues. Often mental changes or people relationship changes can be the most important things in improving team productivity. The SM should assure that all categories of action get a fair hearing from the whole Team.

Alternative Approaches Using the standard approach can work well for several iterations, but Teams bog down doing retrospectives the same way every time. And retrospectives are extremely valuable. So, most Teams benefit from adding variety to this standard approach. Thus, different exercises may be used to generate information at the beginning of the retrospective, etc, etc. See Resources; Derby/Larsen’s book and Kerth’s book for further information. Otherwise, the same basic rules mentioned above still apply. See the Retrospectives section for more information.


General Rules For stakeholders who will not conform to the above rules (as interpreted by the ScrumMaster), the ScrumMaster may bar them from the related meeting (eg, the Daily Scrum). If any team member will not conform to the above rules (as interpreted by the ScrumMaster), the ScrumMaster should get them removed from the Team. While these are an extreme measures, they must be used occasionally. On Timeboxes: The timebox does not mean that you must use all that time. It means that is the maximum amount of allowed time. There are people, most of whom I think don’t fully understand the purposes of the Scrum meetings, who want the Scrum meetings to be much shorter (or not at all). They might say: “Let’s save time for real work by doing the Daily Scrum only twice a week.” We take a very dim view of these so-called efforts to save time. These are essential meetings. The underlying motivation of the would-be meeting cutter, if not ill-founded cost savings, is sometimes the wish to hide some information from someone. On the other hand, we support strongly those who insist that each meeting stay within the timeboxes mentioned above. Partial Scrum: To those who want to play only part of Scrum, our reaction is much like we would have to those who want to play with only part of the rules of baseball. It might be an interesting game, certainly novel. But it is probably ill founded, likely silly, and certainly not baseball. This is not to say that Scrum may not need a few amendments in your situation. This was already discussed in “Changing the rules of Scrum”.


The Story of the Chicken and the Pig Once upon a time, a chicken and a pig, who were friends, were walking along a road talking. The chicken says, "I have an idea, let's start a restaurant!" The pig is thoughtful. The chicken takes a few more steps and says, "I know, it can be a breakfast restaurant. We'll serve ham and eggs." The pig starts shaking his head. The chicken helpfully says, “And I’ll contribute the eggs.” The pig continues shaking his head. The chicken asks, "What's wrong?" The pig says, "I don't like this idea much. I'd be fully committed but, with those eggs of yours, you'd only be involved." Moral: You are motivated differently when you realize that you are fully responsible (perhaps as a Team) for getting the project completed successfully, and that's your only job. You have a different attitude when you are just contributing to someone else's project. Using this story: Some people get upset with this story. Certainly pigs and chickens are both objectionable animals to be compared to. (A ScrumMaster does little better. He is compared to a sheepdog.) Simply put, there are two reasons people object: The story is too accurate; the truth is hard to take, or The story is inaccurate to their situation Certainly, be careful applying one simple metaphor to reality, which is usually more complex. Some people outside the Team can be even more motivated than some team members. But also do not assume we are all honest, self-aware and have good intentions. Equally, “want to” is very different than “have done”. Sometimes, despite our best intentions, the system (the way things are currently organized) does not enable people in delivering correctly on things they want to do.

Useful To Demonize? My experience is that it is seldom useful to demonize any person or group. Our problems are usually not because of “those waterfall people” or “those chickens” or “those managers who don’t get it”. Yes, they are all imperfect, just as we are. Yes, they are in some sense different than we are. Usually if you treat someone with respect, they will eventually respect you in turn. And your ability to influence them will increase. And, yes, it’s OK to hit the punching bag tonight. How to enact respect is not easy to say. We can say that respect includes not pretending to like someone or to agree with someone where you don’t. But let’s return to the basics: first, don’t demonize them within your own mind.


Extreme Programming Extreme Programming or XP is a great way to extend your practice of Agile. I strongly believe in combining Scrum and XP to get a truly effective Agile team going. Kent Beck, Ward Cunningham and Ron Jeffries are the “three extremos”, and probably the best sources for what XP means. This summary of XP will use the organization of Kent Beck’s second book, Extreme Programming Explained – Embrace Change 2nd Ed. Again, buy and read Kent Beck’s book. And read it again. Note: Kent Beck’s description of XP changed in some ways from the first edition of his book to the second. In the simplest terms, perhaps it can be said that he moved from a push attitude toward more of a pull attitude. Wise things said softly are often more carefully attended to. Kent Beck talks about XP in terms of Values, Principles and Practices. You should use the Values and Principles to guide proper attitude in using the Practices.

Note on the Imperative Mood In English grammar they say that certain sentences are in imperative mood. Meaning, they give commands. And you will notice that many sentences here are that way. Just before we said “You should use….” We use this rhetorical device simply for simplicity. It is our general advice. We respect you, and know that you will use common-sense in applying general advice to your specific situation. This is also a pattern we have copied from The Elements of Style. Values In this section, we discuss the values that Kent Beck identifies with Extreme Programming. The values are how you decide if you are doing XP (or Agile) right. Kent Beck: “Values bring purpose to practices. Practices are evidence of values.” Since we have to improvise much of Agile, whether we are doing the improvisation right is a key issue.

Humanity Consider this:

Know then thyself, presume not God to scan; The proper study of Mankind is Man. Plac'd on this isthmus of a middle state, A being darkly wise, and rudely great:

Alexander Pope, An Essay on Man, lines 1-4.

Why start with this quote? Agile has recognized the obvious we blinded ourselves from seeing: that projects are for, of, and about people. This is our study. While we may value other things also (perhaps God), valuing people is an essential part of our endeavor. And we must have some


thinking about what a person really is. Pope says a man is a very mixed creature: darkly wise, rudely great. Kent Beck includes Humanity as a principle of XP and not as a value. I would include Humanity as a value as well. To me, Agile’s first values relate to people. To the customers, to the workers and to the shareholders. Agile puts a great focus on the humanity of the Team and the team members (and all that means). And it wishes to treat each person rightly and fairly, as a human being. Agile, and you working with agile, must handle both the wise and the rude sides of each of us. What do we mean by this? Here are some examples. We are not machines. We are imperfect. We are creative. We persevere when we are motivated to do so. We have emotions, especially toward other people. We learn and have insights that come from…we know not where. We get distracted. We care about the people around us. We like to be in teams (usually). We are internally motivated. More likely by something that we value than by money. The valuing of our humanity is so fundamental to delivering value to the customer, and to having a great team, that I think we sometimes overlook it.

Communication If you are communicating, if the person you are talking to really understands what you are saying, then you are getting there. Usually someone on the Team knows the answer to the problem at hand; just communicate. Valuing communication does not mean we want a perpetual coffee klatch. People are human, but this is a work environment. We do lots of things in agile to communicate better. We always seek higher bandwidth communication, and we seek confirmation that the communication was successful.

Simplicity Einstein said that things should be “as simple as possible, but not simpler.” In Agile we value simplicity. Why? If we keep things simple, we can do less work to deliver to the customer today what he needs for today. Less to figure out later. Less to be pretentious about. Simpler things are easier to add to and build upon. One famous agile phrase is: Do the simplest thing that could possibly work, and then test. (I believe Ward Cunningham gets credit for this one.) Of course, this value of simplicity fits with that. This is not stupid simplicity. This is not making things simpler than they must be. But it is


always challenging ourselves: “Isn’t there a simpler, more elegant solution?”

Feedback Feedback means doing something that gives us information. Then we analyze that information. We form some idea about how we should change things. And then we take action. When we talk about feedback, we mean this whole cycle. Feedback is the basis for learning. And of course, we usually learn from the things we fail at. Try things that might fail, and you will learn more quickly than studying things until you are sure they can’t fail. If your culture doesn’t like the word “failure”, tell them you are doing a “test” that will prove or disprove an hypothesis. Somehow, these words are often more acceptable. Always remember that action is part of the feedback cycle. If we don’t take action, then the feedback was not really there. It was just talk, it was not really feedback. To Kent Beck, the value of feedback also aligns with not expecting perfection or full knowledge up-front. We take the information we have today, imperfect as it is, we make an hypothesis (or a plan), we take action, and we get feedback promptly to determine whether that was the right course. The feedback allows us to start moving toward perfection sooner. When in doubt, generate more feedback cycles.

Courage Beck again: “Courage is effective action in the face of fear.” Agile requires a lot of change. Agile calls for a great deal of honesty, as much as you can stand. Being asked to do your best in the face of all the uncertainty in a project causes fear in most of us. So, Agile requires courage. A courage to face who we truly are, and to face who others really are, and attempt to change them, to have them see it your way. And a willingness to see it their way. A courage to face small failures (learnings). Courage is of course different than foolhardiness. Don’t just do something because it would appear courageous. But when in doubt, be a bit more courageous in trying to do what you think is right. It is quite remarkable to me how what is really important in Agile comes down to the right use of courage. Courage requires action. And it also requires patience. It is often more courageous to be patient (eg, to trust that the Team will produce good software this Sprint after a poor effort in the prior Sprint) than to take action.

Respect As you play Agile, you must respect yourself, you must respect your other Team members, and you must respect the work (the project). Give each Teammate a listen, even after they have let


you down some.11 If anyone on the Team does not respect the project, get him or her out of there. If the project is not deserving of respect, get the project cancelled.

11 In this paragraph I’ve mentioned “playing Agile”. I want you to think of Agile like a game, with some rules but also requiring the initiative of the players to “score”. In addition, I think play puts an added focus on the creative or insightful aspects of project work, which Agile helps support.


Principles Principles are less abstract than values, and a more direct guide to how to develop or use practices.

Humanity Kent Beck’s opening sentences are classic: “People develop software. This simple, inescapable fact invalidates most of the available methodological advice. Often, software development doesn’t meet human needs, acknowledge human frailty, and leverage human strengths.” Wonderful. Beck identifies what a developer needs. This is somewhat like Maslow’s hierarchy of needs. Basic safety – From any threat to themselves or their loved ones. And from fear of losing their job. Accomplishment – To accomplish some meaningful work and contribute something to other people. Belonging – To identify with and be part of a group, and contribute to shared goals. Growth – To expand his skills, abilities, knowledge, wisdom and perspective. Intimacy – To understand and be understood deeply by others. Of course, this list or something like it is also true of all participants in the project, not just the developer (coder) and not just the Team (including the Product Owner). There are limits, of course, to meeting these needs. When we say intimacy, we do not expect work to provide the kind of intimacy we get with our parents, our spouse and our children. Perhaps the intimacy might approach that with our better friends. By meeting these needs, in Agile we expect the Team members to realize more of their full individuality. At the same time that we want that deep Team bond, we want the people to be more the individuals that they are. Remember also the humanity of the people you are building the software for. Think often of them, if you can't actually get them in the room from time to time.

Economics Developing software costs money, and eventually someone (usually the customer or the taxpayer) must pay all that money. Imagine that you build a beautiful technical “solution” that you and a few peers acknowledge is brilliant and elegant. Wonderful. But imagine again that you build something a bit less brilliant and elegant, but something a bit more useful to your friends and neighbors. To me, that is a much greater victory. Some people (including Beck) talk about business value. And some of us feel that is pandering to “the suits”, who can seem to care about no one except their own bank accounts. If business value = profits bothers you, remember that profits usually means you are helping other people. Real


people. Use cost-benefit thinking. And Pareto’s 80-20 rule. It's usually best to do those 20% of things that have the best cost-benefit ratio. And leave the rest for later (after you get feedback on that first 20%). The time value of money. Get something out there, released, that can earn money now. The money earned will help pay for the remaining development. And, as already indicated, that first release also gives you excellent feedback of all sorts. The option value of software. Once some software is deployed, it typically opens up many options. And just as financial options have value, so do those options for the software create value. Get something out there quickly that does one simple task well. Then re-evaluate, for all the other options there are for using that software, perhaps slightly modified, what would achieve satisfaction for other customers, or support other uses by the same customer.

Mutual Benefit Beck: “Every activity should benefit all concerned.” And that this is the most important and most difficult principle. I love almost everything that Beck says, but this seems to go a bit far, at least from what I have seen. Life is not always that convenient. However, his practical applications are quite reasonable (eg, explaining automated tests and refactoring as having mutual benefit). The costs of not having mutual benefit should always be identified. The group should always search for a solution that includes mutual benefit (or the most mutual benefit), and weigh that against other options. Ill-will does hurt relationships, and these relationships in the long term are quite important. (Software development is largely about people relationships.) Extensive internal documentation of software is an example of violating mutual benefit. It slows developers down to benefit an unknown person in the future who must maintain the software, slowing down the rate at which value is delivered to the Product Owner. Beck offers several alternatives that solve the same problems while being beneficial to all. See his book.

Self-Similarity Beck is really talking about patterns here. We should follow organic patterns. If a pattern works in one sphere, use it as an hypothesis in another sphere. If a pattern works in one part of the project, probably you can replicate it in the larger project, or in your smaller, minute-by-minute work. Consider copying the structure of one solution to use in a different context. Not unthinkingly, but considering “what can I copy directly, what must I modify somewhat, and what should I not use?” One set of patterns is the rhythms people have in various activities. Such as a weekly cycle. These organic rhythms tend to give a deep comfort and support to activities that otherwise may feel always too new. Respect the nice timings of these physical, animal and social patterns as you


work on the project. (Example: Support people in stretching after pairing for an hour or two.)

Improvement In his Preface, Beck has a wonderful triple phrase: No matter the circumstances you can always improve. You can always start improving with yourself. You can always start improving today. Do not wait for perfection; you will wait too long a time. Think a little bit, then act, and learn from your actions. This is highly similar to the Deming PDCA Cycle (or Shewhart Cycle): Plan – Do – Check – Act (aka the PDSA cycle). As one application of this principle, we have incremental design, where we consider quickly at the beginning to identify a good design, and continually improve that design as we learn more about the project and about what the best design should be. (Similarly for architecture.) “Find a starting place, get started, and improve from there.” This is in contrast to the unhelpful Scottish travel advice: “If I were you, I wouldn’t start from here.”

Diversity We need different points-of-view about what the problem is, so we can see the problem more fully and more clearly. We need different points-of-view about solutions, so that, from consideration of the options we can find the better option (perhaps not any of the three initially proposed). No one should be taking the lead of someone else “because”,where “because” is followed with any number of useless phrases, such as: “he is my boss, he is older than I, he has been around here longer than I, he spoke up first, she might be upset if I said anything, she might think I’m stupid, etc, etc.” Conflict, up to a point, can be helpful in leading to more productive solutions.

Reflection “Good teams…think about how they are working and why they are working.” Reflection should be embedded in common practices, but should not be limited to them. “Reflection isn’t a purely intellectual exercise.” Listen to your emotions. Mix reflection with action. Learning is reflected in action. Reflection without action is sterile.


Flow “In a barrel of odds and ends it is different; things get mixed up, and the juice kind of swaps around, and the things go better.” -- Mark Twain, Huckleberry Finn We want to deliver a steady flow of value to the customer. So, we optimize the flow of each story. In Waterfall, we identify discrete types of activities to work on in each phase (eg, requirements, design, coding, testing, etc,). In Agile, we focus on letting the stories flow to completion rather than keeping each of those phases distinct. In fact, we want these activities to be as simultaneous as possible. And we want the feedback amongst these activities to be as useful as possible (yet another reason we don’t worry about keeping them distinct). We want delivery to be in as small a “batch” size as possible. Under stress, our human tendency is to increase the batch size, so watch out for that. Weekly deployment is preferred as it provides more flow (and more feedback).

Opportunity Kent Beck: “Learn to see problems as opportunities for” improvement. The right attitude is to use every problem as a platform for getting better, individually or as a Team. Use the existing agile practices or develop new ones so that they help you solve these problems. Need better planning? Use the quarterly long term planning practice. Too many mistakes by one person? Improve your pair programming to address that issue. Don’t be discouraged or slowed down by problems. They are normal. Choose carefully the most useful ones to improve with now.

Redundancy First, we are not after a pure efficiency of resources. We want the continuous flow of value to the customer. As long as we are effective with this, optimizing other efficiencies is not key. So, people can be redundant. And solutions for the people and other problems can also be redundant. Better to assure that the project does not fall into some great difficulty than to keep project costs at their lowest possible level. For example, defects. Beck: “Defects corrode trust, and trust is the great waste eliminator.” Or the lack of trust is the great waste creator. So, many XP practices help assure that the Team generates and lets out minimal defects.

Failure Learn from failure. Learn, and act differently. If you can’t succeed at something, fail. And learn.


“Don’t know which of three ways to implement the story? Try it all three ways. Even if they all fail, you will certainly learn something valuable.” If you take effective action from the learning, the failure is very valuable. We sometimes call them experiments or tests of hypotheses. If stuck, discuss the question for 15 minutes (get a kitchen timer). Then implement something and fail. (Or succeed.) It's faster than analysis paralysis. This is very different than sloppy thinking or poor execution. No excuse for that. This is taking good action on a reasonable hypothesis that may fail, on purpose to learn.

Quality Ask for more quality and get faster projects. Ask for lower quality and you probably will get a slower project. That’s the experience. People need to do work they can be proud of. If you don’t know how to do a quality job, do it the best you can. And improve. Some people on the Team may identify some aspects of quality or different standards for quality that the customer or Product Owner does not wish to pay for. Discuss this carefully.

Baby Steps “Change is unsettling. People only change so fast.” And sometimes they feel the amount of change before them is unachievable. To overcome inertia, take baby steps.12 If you can’t take a big step, take a baby step. Check and see what you learned. And take another step. Examples: test-first programming and continuous integration. Take baby steps as you start to implement them. It is better to take two baby steps forward, than to take one big step forward, recoil, and take two regular steps back.

Accepted Responsibility “Responsibility cannot be assigned; it can only be accepted.” Thus, let the one who will do the work estimate it. The Team doing the work should agree on the work approaches to use in completing the project. Only then will the Team be motivated. Only then will a good Team be effective. Conclusion:

12 As it happens, the Fearless Change book has a pattern that is also called Baby Steps. For much the same reasons.


Use the principles to understand and use the XP practices better. Use the principles to modify or add practices for special situations and needs.


Primary Practices This next section reviews the primary XP practices, as defined by Kent Beck.

Sit Together “Develop in an open space big enough for the whole team. “ And balance that by doing other things to meet the needs for privacy. Communicate with all your senses. Face-to-face communication is usually best. The common space enables many things, including a sense of common team purpose, face-to-face communication, brainstorming, feedback, and improvement. You can creep up on sitting together. Do not tear people from their private cubicles before they are ready. Perhaps they keep them as well, for use part-time, to provide for their need for privacy. Can this practice be violated (with distributed teams) and the project still be considered agile or XP? Yes. But do not turn away from this practice without considering the full costs carefully, including especially the reduction of or delay of benefits from the project. Definition: Sit Together talks about the ideal of a collocated team. At the extreme, collocation means that the team is in one team room all day, every day. The opposite of a collocated team is a distributed team; I guess the extreme of that would be a team of 12, with one person in every other time zone around the globe.

Whole Team “Include on the Team people with all the skills and perspectives necessary for the project to succeed.” People need to work on teams. They need to belong; they need to feel they are in this together with others; they need support from others. Try hard to avoid fractional people. Don’t readily accept people being allocated 40% or 60% to your team. They will be less satisfied and the Team will feel their lower commitment. In almost all cases, it is more productive to be allocated 100% for a few weeks than to be 60% for the same total hours over a long period.

Informative Workspace Use the workspace to make the important information visible and clear for everyone. The key things should be inescapable. Alistair Cockburn has termed these “information radiators”, which is a catchy phrase (not clear who originated the idea; probably an ancient idea reborn). Usually that workspace starts with the walls in the team room, and particularly any whiteboards on those walls. Some informative workspaces start with pseudo-walls.


Beck: “An interested observer should be able to walk into the team space and get a general idea of how the project is doing in 15 seconds.” Story and task cards (using small post-its or cards with magnets) can form the iteration backlog. Big visible charts are another idea for informative workspace (or information radiators). Keep the workspace uncluttered and get rid of information that is no longer useful. Always keep the most important stuff on the top.

Energized Work Beck: “Work only as many hours as you can be productive and only as many hours as you can sustain.” For some, working long hours seems to be a macho way to prove one’s virtue. Software development is not about the hard work of just lifting more bales of cotton each day. It is about creativity, insight and working together. These can only be done fruitfully for a few hours each day. It is easy to remove value from a project when you are tired. And, at that time, also hard to notice the value draining away. Consider other ways to energize your work. Consider ignoring email and the telephone for a 2 hour stretch each day, and focusing on the immediate task cards.

Pair Programming XP is justly famous for pair programming, and almost everyone I talk to who does not like it has a false notion of what it means (at least in my opinion). Two heads are better than one. That’s it. That’s almost everything that it means. Benefits include (per Beck): Keep each other on task. Brainstorm refinements to the system. Clarify ideas. Take initiative when their partner is stuck, thus lowering frustration. Hold each other accountable to the team’s practices. Pairing does not mean working with the same person 8 hours a day, every day for a year. Pairing does not mean that a better programmer must re-do his code merely to suit a less-experienced programmer. Consider pairing for all the activities that the team does, not just for coding. Pairing does mean that we try to keep everything so simple that anyone on the Team could understand it. That way, if someone gets sick or is busy with something else, at least one or two others can revise or refactor that code (or whatever it is). Pairing does not limit the size to two. Some things should be worked on with 3 or 4 people.


Part of the logic of pairing is in how writers and editors work. It is hard to create and edit at the same time. Thus, one person takes the creative role, while another is editing the work in real time. Work alone some too. But bring it back and share it with the Team. Many people who do IT work are introverts (surprised?). Often introverts will have almost physical limits on how long they can work with other people. It does often depend on who the people are. Peer pressure should not force these introverts to pair too long.

Stories Kent Beck starts each practice with one line that summarizes the whole thing. For stories he starts: “Plan using units of customer-visible functionality.” So, while stories (or user stories, as some call them) are great for communicating requirements, they are mainly for planning. Why? It is through planning that the customer uses Pareto’s 80-20 rule to identify the 20% of requirements that will release 80% of the business value. (Ah, yes. When it comes down to it, not all the requirements were really required, for the first release at least.) Stories should immediately be estimated for Business Value (as defined by the customer or Product Owner) and for effort (as defined by the Team). This enables the cost-benefit discussions that prioritize the stories. To get the greatest benefit from the least cost. Beck’s example is a Ferrari for $150,000 or a Dodge minivan for $25,000. Until we see the cost, many of us might prefer the Ferrari. The 3 C’s: Put the stories on cards, and the cards on a wall. The cards represent the conversations that assure that the whole team is always checking “do we really understand the whole story”. The last of the 3 C’s is confirmation. Know right away how you will confirm that the story is complete. I often put this on a “conditions of satisfaction” card for each story. Mike Cohn has additional great ideas for User Stories. See Resources.

Weekly Cycle Weekly cycle is very similar to the Scrum “sprint” idea. The weekly meeting has the key concepts of the Sprint Review meeting and the Sprint Planning meeting. Review progress, pick stories for the week, break out and estimate tasks. Beck likes the ownership of specific tasks, which meets the human need for ownership. The Team develops a weekly heartbeat. Do not carelessly disrupt this rhythm. It gives the Team a platform for experiments. “Start the week writing automated tests.” Then do everything else. Then celebrate progress at the end of the week. Beck prefers to start the week or the iteration on a Monday. It is also a natural rhythm. One thing we want is to minimize is the Team working weekends, but of course there is no guarantee of that, no matter when you start. But it is not critical to start on Monday.


Mike Cohn prefers to start on a Thursday or Friday. This helps the Team avoid the temptation to work on (or rely on) the final weekend before the iteration ends. Much to be said for that. How important is planning? Well, you have to have some, but you want to apply the 80-20 rule. After a point, incremental time devoted to planning does not improve its accuracy much nor help the work go better. So, consider reducing the planning part of the iteration’s or week’s work as you learn more about the project. Not always possible. Sometimes you learn things that require the Team to re-estimate the remaining Product Backlog (or stories).

Quarterly Cycle Beck: “Plan work a quarter at a time. Once a quarter reflect on the team, the project, its progress, and its alignment with larger goals.” Quarters have a nice rhythm to them. It is the seasons built into us. And many other things are built on quarters. I would tend to plan more by release. And I would typically want to have a release at least every two months. But I like having a bigger retrospective every 3 months, and looking at the bigger picture. If you want to do both quarterly planning and release planning, watch out that you don’t get yourselves confused thinking about things that it adds no value to think about yet (eg, things no on the next release). Sufficient unto the day is the evil thereof. And sufficient unto the release are the problems thereof. What you are looking for is that simultaneity of vision: seeing the big picture (or how the big picture is developing) and yet also able to focus on the details of today. It’s a balancing.

Slack Allow slack (eg, by having minor tasks that can be dropped) so that even with problems you can still make your major commitments for the iteration. Beck’s main argument for this is that trust is precious, and generally lacking. So, you need slack to build up the trust that evolves from keeping the commitments the team makes. Very important. Beck also mentioned the incredible waste generated from over-commitments and trust broken. And the effects on people that lead to reduced productivity. But there is another side too. Creative work is somehow magical. It “comes to us” from time to time. And we have to give our minds focused time to be open to that insight coming to us. Therefore we need a certain kind of slack. It is by indirections that we find directions out. Somehow, a divinity shapes our course, roughhew it as we will. Slack is not simply being lazy. It is focused openness. Or perhaps disciplined listening.


Ten-Minute Build Beck: “Automatically build the whole system and run all the tests in ten minutes.” Ah. It isn’t just the build in 10 minutes. And you must run all the tests, so that the builds will be done frequently, throughout the day. Whenever it feels like time to take a mental break and get a cup of coffee. If you aren’t to that point today, where do you start? Start by building just part of the system automatically. Then build the whole system automatically. Then tune the build so it can happen in less than 10 minutes. Then add a bunch of automated tests (the most important ones). Then add tests and tune the tests, until all tests run in 10 minutes.

Continuous Integration Beck: “Integrate and test changes after no more than a couple of hours.” This is assuring that no coder is more than ah hour or two away from integrating with the rest of the team. Best to pull this all together with the 10-minute build, including the tests. Why? We want fast feedback to the developers, if there are any errors or regression errors. This allows them to understand and fix any defects quickly. And to start new work knowing there are no defects in the old work. A great comfort when you are afraid of the dark. The integration should ideally also be all the way to the end. All the systems involved. And build the final product (eg, Beck’s example is “if the goal is to burn a CD, burn a CD.”) You find out about every possible problem in the deployment as soon as possible. Give reality a fair chance to bite you sooner, when it won’t hurt as much.

Test-First Programming Beck: “Write a failing test before changing any code.” Very simple. Understand the test, then just pass that test (nothing extra). This gives these benefits: controls scope creep, decreases coupling and increases cohesion, builds trust, induces a good rhythm, and keeps focus. Why? One answer: To get faster feedback that I have succeeded or failed when I write the code. The tests are small, so they run fast. It does take some experience to make the tests cover a wider set of risks. What if your testing is not automated today? Start building every new test as an automated test. And selectively build regression tests to be automated. Where there is the most risk. When crunch time comes, manual tests are omitted. As Ron Jeffries says, that’s like turning off your headlights at the darkest time of the night. What if your situation (people or otherwise) won’t allow automated tests? Well, at least get agreement that we design the tests first, and only code to pass the tests. And that the speed and frequency of testing feedback (even if manual) is extremely important. Every time a defect is found, ask about the impact of not having found it sooner.


Incremental Design Beck: “Invest in the design of the system every day.” Every day we learn something new about the system, so every day we invest in the design by refactoring as much as necessary to get the coupling and cohesion to the right levels (down and up). Incremental design is no excuse for starting off with no design or an ill-considered design. But experience has taught us that we live and learn. And that the better design emerges as all the parts interact. The question is not: do I do design? The right question is when do I design. And the answer tends to be, as close as possible to when I get real information about whether one aspect of the design is really needed or will really work. So, it comes down to a judgment. Have we designed enough to start? Or, how much more do we need to refactor the code to match the new design before continuing on building new functions? Some individuals and some teams don’t put enough time into design early on, or even along the way. Others still go in for BUFD (Big Up Front Design), which by definition means too much. (But bigness is relative to the size of the project.) Use good judgment. There is a big economic benefit in deferring the decision on a design question. Often YAGNI (you ain’t gonna need it) is true. Often resolving a design issue (ex: to support functions to be developed in release 2) should not be paid for in release 1. If you actually follow plan, you can pay th incremental design improvement in release 2. If you have a big design question where an answer does not appear quickly, consider attacking that problem by trying to prove whether one design solution or another will work. Create a story that will generate that proof. Don’t get trapped in analysis paralysis. Yogi Berra: “When you come to a fork in the road, take it.” How much do I refactor? Ans: Have you eliminated all the duplication?

How do we start with XP? In heaven, they start Agile using Scrum and all the XP practices on day 1. On earth, this is too much to ask of most teams. In our ideal earthly scenario, you would start with Scrum and some of the basics of XP (eg, the whole team, a customer (Product Owner), 2-week Sprints, stories for PB items, sitting together, an informative workspace, and energized work). And some pairing (a common-sense thing that everyone does to some degree). Immediately you will have some version of incremental design. Once the Team has that down, start experimenting by adding more XP practices. I’d start with test-first programming. Then 10-minute builds. And then improve incremental design. And then improve each of the existing practices. Don’t expect each of these XP practices to come easily to you (the Team). Give them time and the new practices will pay benefits. If you find something isn’t working well, consider reverting for a time to your old practice. Probably other things need to be more engrained before the “troublesome” XP practice can help


you.

Who decides? This is a controversial question in Agile. Before answering, let’s make some observations. First, people tend to be best at doing what they want to do. So, when implementing new ideas, it helps that the Team at least not feel forced into doing something they think is stupid. Second, since most Teams are more interested in technology and similar subjects than in “process” (or whatever label you want to put Agile under), the Team is often unlikely to propose doing new things in Agile. It happens, but not often, and when it happens it tends to be selective (just the practices that one person likes). So, we are not against some outside agent making a case for a new Agile practice. This might be a manager or an Agile coach or whoever. My answer: There is no pat answer to this question. It depends on more things than we have room to discuss here.


Corollary Practices

Real Customer Involvement Beck: “Make people whose lives and business are affected by your system part of the team.” On one level, this is exactly what Scrum does by including the Product Owner as part of the team. But this is a step further. Talk directly with the person or people to whom you want to deliver business value. Put as few filters on that as possible. Increase the communication and feedback. Stretch your team this way. What if you have many customers? Beck’s answer: Build what one or two real customers want. It is easier to generalize a system than to specialize a system that never solved a single person’s problem.

Incremental Deployment Beck: “When replacing a legacy system, gradually take over its workload beginning very early in the project.” Big deployments can work, but they are costly one way or another. Yes, incremental deployment has some costs (minor compared to the reduced risk). And incremental deployment gives you feedback on what you didn’t understand, so that the next iteration can correct those misunderstandings.

Team Continuity Beck: “Keep effective teams together.” Do not call a person a resource. People are not things. And a collection of individuals is not a team. Do not try to treat people like things; they sense that and each bit of it makes them less effective. Respect the power of a successful team, and give it more good work to do. Respect the relationships, and the trust, and the knowledge of each other’s strengths and weaknesses. This advice does not mean that a team should remain completely static forever. Ask one person to move from this team to that team, because it’s needed. Make other changes when necessary. For example, every 12 months or so for a team that has had no changes, let one or two people move, just for variety’s sake.

Shrinking Teams Frankly, Beck had not used this practice himself before he mentioned it, and I am not sure it makes sense to me. Read his book and see what you think.


In a different way than he described, I have seen this. Some Teams think they need to be 10 people at first, to include all the special abilities that will be needed in the project. If enough learning occurs during the project, it would be good if the core team members reduce down to about 7. Seven is the ideal size for optimal team communication.

Root Cause Analysis Every time a problem is found, eliminate the problem and its cause. This should be done for software defects (errors, bugs) and for any other type of problem. The goal is not to eliminate one defect, but to improve the team’s “system” so that fewer and fewer defects ever occur. System is a word that Deming used. It means the people, the process, the environment, indeed the whole ecology in which work is done. Taiichi Ohno proposed the Five Whys. This is where you ask why the problem occurred. And then to each answer, one asks why again, four more times. And then one fixes all five causes along the way, or perhaps only the root cause. Beck notes that the source cause is almost always a people problem (eg, someone didn’t understand, for example).

Shared Code Beck: “Anyone on the team can improve any part of the system at any time.” This assumes that the Team, and all the people on the team, have a sense of shared responsibility. Of being in this together. And that people will have the sense not to dip into parts of the code they don’t understand, at least not alone. The benefits include these two: the ability to fix things quickly, and a reduced reliance on any one person. Why? Two heads are better than one. One person may think that the code’s logic is clear and complete, but if two or more also agree, then it is more likely the code is really robust. This practice works better if a good form of the Continuous Integration practice is already in place.

Code and Tests Beck: “Maintain only the code and tests as permanent artifacts. Generate other documentation from the code and tests.” Beck doesn’t mean this quite as completely as it sounds in these two sentences. He does mean, I think: never let documentation substitute for communication. The history of the project probably does not need to be documented. You only need the information that will allow people later to take effective actions or use the system effectively in the context of the business use. Every extra page of paper or paragraph just gets in the way of the usable information in any documentation. Using Pareto’s Rule, my recollection of some situations is that perhaps 80% of current software documentation was waste in terms of the best use of the resources needed to create that documentation.


Use continuous improvement to have the Team continually eliminate or reduce documentation that isn’t clearly much more valuable than its cost.

Single Code Base Only have one code base. Greater simplicity. If you have more than one code base, reduce or eliminate all but one. If you have strong reasons for having multiple code bases (eg, each customer needs a different version of the system), challenge the related assumptions. Fix any underlying design issues that seem to require multiple code bases. Why? One code base means less work. Less to think about, fewer bugs, etc. This increases the ability to respond quickly to a customer need. One argument used for multiple code bases is that it seems to allow more programmers to be busy coding. Yes, they seem busy more of the time. But the results are less productivity (because of more confusion, more defects, effort to integrate the code bases, etc). Optimize overall productivity, not appearances of busy-ness.

Daily Deployment Beck’s idea: “Put new software into production every night. Any gap between what is on the programmer’s desk and what is in production is a risk.” What this means for most of us? In a phrase: Deploy twice as frequently (as you do today). This is a corollary practice because there are many prerequisites, such as: very low defect rate (probably a full automated testing harness) automation of deployment and roll-back trust between the developers and the customer Compare deploying once a year plus monthly bug fixes. Rather than do that, wouldn’t it be better to deploy a small piece of new functionality each month? Often people feel deployment is “too hard”, so they want to do it less frequently. But the reverse reaction should be true. It should be something that we can use to learn from, and putting in that effort to lean out the deployment process will help give us better feedback, and make us more productive.

Negotiated Scope Contract Write contracts that fix time, cost and quality, but leave scope open. In other words, we may have a fixed team working consistently, an agreed date for the next release, and a standard for the number of acceptable bugs (eg, no severe bugs), but exactly how many stories will be done for that next release is left open to change. It is a good practice to work on some projects that think and work this way. This prepares you and the team for when you must write a contract structured this way, and then perform under that contract.


An alternate pattern to follow is to fix scope, but not the release date. The key idea here is that often, exactly when there is “enough” functionality to release will emerge over time in the eyes of the Product Owner (or the team). He needs to be aggressive about trying to release something early. Once he sees “it”, he then asks for a few tweaks, and that the product be released “in two weeks”. See Kent Beck’s and David Cleal’s paper on optional scope contracts. See Resources.

Pay-Per-Use Kent Beck: “With pay-per-use systems, you charge for every time the system is used.” Money is a very simple, concrete, un-confusing form of feedback. Or at least can be. Even if you don’t use pay-for-each-use, the same idea applies in releasing more frequently. (For 6 to 3 months. Or from 3 months to 1 month.) You earn some value, and that actual value received gives you feedback about whether you are on the right track. Ideally, it also gives everyone on the team more energy to continue on. Pay-per-use can be contrasted with pay-per-release. Here the interests of the user and the supplier may be mis-aligned. (The supplier wants more releases for more revenue, while the user may not want the full cost of the upgrade, which typically is not just the cost of the release.) So, try to arrange things so that your customer relationship is more like pay-per-use than like pay-per-release.


A Few Things We Haven’t Talked About There are actually a great number of things we haven’t talked nearly enough about. Depending on the situation, the larger Team may need to talk about and decide about almost any of the different things that have ever been mentioned in relation to an IT project. But be careful. Talking about anything or everything takes time. Use the 80-20 rules again, and discuss those things that are most meaningful for your project. Adopting Agile: Since this book is not mainly for the Evangelist13, we have not dwelt on this subject. But Agile is a long-term change initiative, and the Evangelist and others must deal with the whole life cycle of change adoption. Note that Scrum and XP are built to ride the cycles of change. See Fearless Change by Manns & Rising. Starting Up: We have not talked much about the effort, in several areas, to get a project started. We specifically have not talked about Rapid Planning, Project Discovery, the Planning Game, or the other names for the beginning-of-project activities. This is partly because, in the agile community, there is not as much agreement about what would be too little in this area, and what would be too much. My bias is that the right amount depends on the project, the team and other factors in the circumstances (eg, the needs of some stakeholders). On-going Planning: We have implied that there is some planning every iteration, at least in terms of the new iteration. We have not talked about how to embed the different aspects of planning with the rest of Scrum or XP. Mike Cohn’s book on Agile Estimating and Planning discusses this, as do others. Lean: We have not discussed Lean ideas nearly enough. People Issues: This may be the most important thing to address. And the most difficult. As several have observed, the root cause of most problems is a people issue, in some sense. We have made some helpful comments along the way, but arguably not enough. Continue to think for yourself on this topic. It is perhaps worth repeating that people (singly or in groups) are greatly affected by their conditions and by the overall system in which they work. As Raul Julia said about Mel Gibson’s affair with Michelle Pfeiffer in Tequila Sunrise: “You don’t blame a compass for pointing North.” In a similar way, Deming was a strong advocate for almost never blaming the workers.

13 Another pattern from Fearless Change.


Retrospectives Retrospectives are perhaps the single most powerful lever for making project teams more productive. And projects. And teams. This assumes there is a will to take action and that the retrospective is done well. Derby and Larsen recommend a five step agenda for every Retrospective. Set the Stage Gather Data (one of a number of exercises) Generate Insights (one of a number of exercises) Decide What to Do (one of a number of exercises) Close the Retrospective They also propose a set of activities for each of these steps. See Agile Retrospectives in the Resources section. Key insight: In our rushed lives, we want to jump straight to “decide what to do”.. The problem with that is the frequency with which key ideas and insights of a higher priority are lost. So, if you set the stage right, you will gather more useful data. Having more data will lead to better insights into what the most important problem is. Having identified the most important problem, the actions will be more effective. We do not recommend working on a long list of blocks at the same time. Pick the vital few. (Sometimes a team can deal with a block better just by recognizing it, so that can be useful if done quickly.) Throw the Change-up14: Change how you do the retrospective to release hidden issues. Even if your basic intent is the same, the different method will uncover new issues. Changing the people doing the retrospective can release new insights. Typically adding a person is more useful than taking a person away.15 Use an outside facilitator when the team is having a tough time. This can be very helpful, as it injects a neutral party and allows the usual facilitator to participate in the event. One pattern: Two teams can simply swap facilitators. Don’t accept mediocre retrospectives. Get the real juice from them.

14 A Change-up in baseball is when a pitcher throws a pitch that looks like a fastball, but actually comes to the plate much more slowly. 15 I stole this insight from Michael Feathers.


Business Value: What is it? What do we do about it? The following article is an introduction to Business Value. A topic that gets too little discussion. The goal of any project is to deliver business value.

What is it? But what do we mean by business value? Some of us have thought about this quite a bit, but many people on agile teams do not think about this much. First, we mean that we are not doing the project just to amuse ourselves. We are doing it to satisfy someone else. Or perhaps a large set of customers. Customers: This brings us to the first possible definition of business value. As Lean says, value is defined in the eyes of the end customer(s). Value is meaningful when talking about a specific product that meets a customer’s needs at a specific price at a specific time. I can’t keep track of what my wife wants from moment to moment. Indeed, I can’t keep track of what I want. So, this is not as easy as it might sound. Interestingly similar to this from Peter Drucker: “The purpose of business is to create and keep a customer.” Everything else is just a constraint. NPV: In business school I was taught another definition of business value. This is the value of the business to the shareholders. In this realm, discounted cash flows were king. So, one looked at the outflows (eg, investments or costs) and the inflows (eg, revenues) over the lifecycle of the product. And that determined the product’s business value. Using a bit of math, this gives the NPV (net present value), by which all products or projects or investments might be compared. A level playing field. If one makes the right assumptions in the math equation. Sometimes we call this ROI – Return on Investment (I won’t quibble here about the differences). It turns out, though, that people don’t buy products really. They buy solutions to their needs. This thinking aligns well with value as perceived by shareholders or suppliers of capital. Comment: Most shareholders are quite comfortable that the firm is taking reasonable risks. Some reduction of risk is important to them, but they are quite realistic that all risks cannot be eliminated or even reduced. Managers, on the other hand, with less diversification of their income stream, are often highly adverse to risk. Use balance when you adjust the NPV discount rate for risk. Workers: There is another business value that we should also consider. It is said that the most important assets of any company go up and down the elevator every day. The workers. By which I mean all the people who voluntarily come together to make the business happen. (Yes, they are volunteers.) This includes the managers. How do they see value? In my view, we have not done as much thinking on this subject. Perhaps we can say they want a better and more fulfilling life. A worklife that is not so crazy and a sense that they gave to a good cause, that their life means something (because of their work), that they have done all that they could do. Is your project better in this way today, compared to yesterday? So, I suggest that business value has to do with all three of these constituencies: customers, providers of capital, and workers.


OK, once you select who (from these groups) defines business value, then the question becomes, how do I get the best information about business value into the Team. Because, I suggest, the better the Team understands business value, the more effective it will be. I have never seen a Team that understood the business value too well. Let me emphasize this with two quotes: “You've got to be very careful if you don't know where you're going, because you might not get there.” Yogi Berra “There is nothing so useless as doing efficiently that which should not be done at all.” Peter Drucker. Thus, it is more important to do the right thing, than to do things right. Far too many projects lose sight of this simple truth. One place to start is to have the right attitude toward business value. It is confusing - it is easy to think you understand it when you do not. It is something that you learn about all along the way, it is not static. Respect that. Respect that the Product Owner is not today the font of all wisdom on business value. He and others must learn about it together over time. Tools In working on business value there are many tools and tricks. Don’t get overly involved with the tools and tricks. Do something simple first, and always question whether you really have the right information. With trepidation, let’s now discuss a few of the key tools (there are many others). Kano Model: Mr. Kano came up with this approach in the late 1980’s. This is a simple tool that suggests you can sort any feature or aspect of a product into one of three categories. “Surprise & Delighters”, those things that the customer does not expect, but would excite him if the product had them. “Must-Haves”, those things the customer assumes the product must have. In-between: “More is better”, for a thing that the product has, but could have to a greater degree, so that having more of it would be better. Value Stream Mapping: This is an important tool in Lean. Lean argues that shrinking the duration of the overall value stream to the customer, eliminating that wastage of time, has benefits for everyone, especially the customer. It is far more involved than just the notion that the customer wants his identified need satisfied immediately. Customer Metrics: There are “lies, damned lies and statistics,” so be careful when you use these. Still, they can be helpful. Usually these are measurements of things like customer satisfaction, quality, speed of delivery, price to the customer, and other product factors. Which metric(s) is important will vary from project to project. Thus, multiple projects are typically not comparable by this means. Dollar Metrics: As hinted earlier, it is very useful sometimes to be able to compare products or projects on an apples-to-apples basis. In addition, dollar metrics are something that everyone can understand. Something worth $100 is clearly a lot more valuable than something worth $10. Typically these metrics are from the shareholders viewpoint, so that limits their usefulness. We have already mentioned NPV and ROI as examples. Let me pick on cost savings attempts. If a cost savings is being passed on to the customer, most


customers like that, at least to some degree. But that assumes that the aspect of the product the customer most wants improved is cost; not always a correct assumption. If the cost savings is only for the firm, the real benefit stands on even less firm ground. If we take this to its logical extreme, the firm should reduce costs to zero. And go out of business. But clearly that is not very useful to anyone. It seems clear that far too many firms have focused too much just on gross cost savings. In accounting terms, the top line (revenue) needs to grow too. What do customers want?: We are all customers, so think about what you and your friends want. Compare things you each bought today, and why, and talk about the differences. The basics of what we look for are well known (perhaps too smugly well-known): product features, quality, price, timeliness. Each of those seems simple at first, but then get more involved upon further thought. Think about buying a Disney vacation for the family. Who actually is the customer? What really is the product? Etc. Etc. Relatively recently people have added “customer experience” to that list. Starbucks is a prime example of this. Anyone can make Starbucks coffee. But the experience is what people really buy there. People want everything until they have to pay for it. That’s when you find out how valuable a product or service is to them. Customer Proxy Almost every project I have been on has someone I call a customer proxy. This is the person who explains what the business value is. In Scrum, this is the person with the Product Owner role. Think carefully about how well that person can reflect the true business value (no matter which definition of business value you use). Is that person a good proxy for the external customers? Or for the shareholders? Or for the workers? All three? Ask the Product Owner to explain how he determined the business value, and why he feels that approach to Business Value is the correct one. Consider getting additional, more direct sources of business value information (eg, talk to real customers). Consider experiments to test whether the business value posited will actually be realized. If discussed with the right attitude, any good customer proxy will appreciate good ideas about getting better information.

What do we do about it? Well, in some ways, we have already started talking about what to do about Business Value. Let’s say you’re a senior developer on the team or maybe the ScrumMaster. Or maybe even the Product Owner. Maybe your project is already under way. You’re going to do what you want about business value (including possibly nothing), but here’s what I would suggest. Perhaps the most important thing to do is learn more about business value. Both generally, and what it means for your project. Talk to your customers. Talk to them some more. And take action on the new learning (eg, re-prioritize the stories). Now let’s be more specific.


First Task: Make sure the project’s business value has been explained to all members of the team satisfactorily. Satisfactorily? What do I mean by that? If the business value is not crystal clear to every member of the team, you are not done. Crystal clear means that the business value is so obvious and so clearly important, that each team member is proud to talk about it to anyone. To their mother or their spouse. To other people in your firm. And maybe so clear that the project is scary. I mean, we (the team) are responsible for delivering that! And everyone is watching! What if we don’t fully succeed? Crystal clear means that the business value is understood and is motivating to all the team members. How can you tell if they understand it? Ask them to explain it to you! What if it is not? Second Task (optional? probably not): If the business value is not crystal clear, fix it. Make the product owner talk. Review it with any member who doesn’t “get it”. Fire team members if they still don’t get it (however good they are, you don’t need any uncommitted team members on the team). Or hire a new product owner. I am quite serious. This is your life. Don’t you want to accomplish something you can really be proud of? Well, get a product owner who can see and articulate some really important business value. And when you deliver that, then you can rightly and proudly talk to anyone (including especially yourself) about what you helped accomplish in 2007. And then in 2008. And so on. Third Task: Even if it was crystal clear, discuss business value again. Even though some of us take marriage vows, it appears some of us forget. Same is true of business value. And then we know that things change and we live and learn. So maybe the business value itself or at least our understanding of it has changed. Shocking, I know, to us in Agile. And worse, our real understanding if business value is not that good. Some of us are sure that business value is all about ROI or NPV. Works well for the stakeholders. But, as discussed above, there are other, perhaps better definitions. Peter Drucker and Lean say that business value is defined by the customer. And customers want products and experiences. Now, at the lowest price, with better quality. And trying to figure out what “most” customers really want is quite hard. Re-assess. Make sure the new learning has been communicated. Maybe talk about all kinds of business value (customer, shareholder, and worker). We are most certainly not doing a project just because some stupid Product Owner says so. Trust ‘em, but make ‘em prove it to you. And also respect how difficult it is to know the future. No business person really knows the future (which is where the business value always lies), anymore than you really know the future (eg, can predict with much accuracy when your project will complete). We have not mentioned all the issues around the business value of risk or compliance. Do most Product Owners on these kinds of projects really think they have articulated business value in a


way that motivates the team? Baloney! Try again. Fourth Task: Bring it down a level or two or three. Just as we need focus, direction and motivation at the project level, we also need it at the release, epic, theme and story level. Every story needs some cost-benefit analysis, because this will often affect how we implement that part of the system. If the business value of one piece is $10,000, you just don’t invest $20,000 of effort to create that functionality. If the business value of piece A is $100,000 and piece B is $50,000 (other things being equal), it becomes crystal clear to everyone why you work on piece A first. It is not because “the product owner said so”; it is obvious. This is not so easy to do? Yep, it ain’t always a picnic. But projects weren’t meant to be picnics. The Team (with the Product Owner) is pretty darn clever; figure it out. (More suggestions on this will come later.) Take the baby steps to get a little bit better each time. Just like with everything else on the project. Fifth Task: Talk about business value outside your Team. Talk about the business value your team has delivered. In clear terms. To others in your firm who have nothing to do with your project. Write short notices about your project for all to read (use email, a newsletter, whatever). Why? Agile will penetrate into the rest of your firm not because it is cool or trendy or fun. Or people like to do it. It will penetrate because it ought to. Because it delivers business value for the 3 main constituencies that all firms were born to serve: customers, workers, and capital providers (including shareholders). Because your firm will not survive and prosper without it. But the only way the late comers (the people Manns & Rising calls the Late Majority16) will be convinced is evidence. And the evidence almost all of them can understand is business value. If they hear it again and again from various projects, they will see that doing Agile is the obvious choice. A no-brainer. But they won’t get to that conclusion unless all the agile teams in the firm can articulate the business value you are delivering better. Final action item: Eschew costly, unattainable and unnecessary precision. Rough accuracy is good enough for virtually all business decisions. Well, those are my suggestions. Think for yourself. And do what you think is best.

16 Late Majority is a pattern mentioned in Fearless Change.


On Agile Adherence Often the question comes up: how important is it to adhere closely to all the Agile values, principles and practices? Perhaps this is for you an easy question. For me, it is not. I have never seen Agile perfectly implemented. I have not noticed that the wrath of God or a similar calamity has been visited upon that team or that group because of that. My experience is that teams always benefit by being more Agile, by adhering more to the values, principles and practices. And the only important cost is in their psychic energy to make that change. It is very useful to have an ideal (perhaps an ideal for “the best” Agile) and to strive toward that ideal. It is not useful to achieve that ideal and become complacent. None of us are perfect, and none of us is going to be perfect. But I can be somewhat better today. And perhaps, working together, we both can be somewhat better. Agile adherence is not useful in itself. It is useful because it makes our work better. It is useful because it allows our customers to receive more satisfaction. My suggestion is that the idealists and the pragmatists on this subject continue to learn from each other. While muddied sometimes with other noise, they both are telling us something useful.


Some Agile Quotes As coaches and as team members, our work can get awfully serious. As humans, we need a laugh now and then. At the same time, humor can be the nutcracker to open our sealed braincovers. And humor can be the peg on which we remember more complex ideas. Some people think that Agile was invented yesterday. Or in 2001. Or in the early 1990’s. (There is some truth to the last statement.) The real truth is that one of America’s great yogis, Yogi Berra, invented most of Agile between 1951 and the early 1990’s. As evidence, I submit the following quotes to a candid world. Yogi was both a baseball player and a baseball coach. Some of his comments touch one or the other, or both, roles. And they touch the Product Owner, customer and business roles, too. The Evidence "This is like deja vu all over again." "You can observe a lot just by watching." (aka Berra’s Law) “It ain't over till it's over.” "Think! How the hell are you gonna think and hit at the same time?" "You've got to be very careful if you don't know where you're going, because you might not get there." "I knew I was going to take the wrong train, so I left early."17 * "If you don't know where you are going, you will wind up somewhere else." "Baseball is 90% mental -- the other half is physical." "It was impossible to get a conversation going; everybody was talking too much." * "Slump? I ain't in no slump. I just ain't hitting." "Nobody goes there anymore; it's too crowded." * "If you come to a fork in the road, take it." "90% of the putts that are short don't go in." * "I made a wrong mistake." * "Yeah, but we're making great time!" -- In reply to "Hey Yogi, I think we're lost." "I never blame myself when I'm not hitting. I just blame the bat, and if it keeps up, I change bats. After all, if I know it isn't my fault that I'm not hitting, how can I get mad at myself?" “If people don't want to come out to the ball park, nobody's gonna stop 'em.” *

17 See the note on humor at the end. Starred items are “explained” below.


“In theory there is no difference between theory and practice. In practice there is.” “There are some people who, if they don't already know, you can't tell 'em.” “We made too many wrong mistakes.” “It's tough to make predictions, especially about the future.” “It ain't the heat; it's the humility.” “If the world were perfect, it wouldn't be.” “If you don't set goals, you can't regret not reaching them.” “Pair up in threes.” “I wish I had an answer for that, because I’m tired of answering that question.” * “If you ask me anything I don’t know, I’m not going to answer.” * “I knew exactly where it was, I just couldn't find it.” "It's not too far, it just seems like it is." * "I didn't really say everything I said." In fact, while most of these quotes were indeed spoken by Yogi, it is believed that some are merely ascribed to him. But have fun with those anyway.

Note on humor It is said that, if you have to explain a joke, it ain’t funny no more. But in fact all of these quotes are here to educate. So, I will try to explain a few, by why of helping you think them through. Most of these are so good, you could interpret them many ways. "I knew I was going to take the wrong train, so I left early." Allow some slack time in the iteration. You’re experienced; you know that somehow the team is going to have some difficulty, perhaps self-inflicted, and need some “extra” time. "It was impossible to get a conversation going; everybody was talking too much." First, documentation does not substitute for communication. And a lot of talking is not necessarily communication. We are not looking for a lot of talking; we are looking for useful understandings to be communicated. (And I am also sympathetic for those who feel some team rooms are too darn noisy.) "Nobody goes there anymore; it's too crowded." Somebody in the team will say, “Let’s do X, everyone is doing X”. Maybe the person will complain about Agile, and say that everyone is doing Waterfall. But nobody important does things because the crowd does them; usually the opposite.


"90% of the putts that are short don't go in." This gets at Beck’s issue of having courage. Don’t hold back; give the iteration all the creativity that you have. Of course that courage won’t guarantee perfect results, but your best results will never come from giving only 80% of your best creativity. "I made a wrong mistake." A lot of people in the IT field have the perfectionists mentality. This one just says: loosen up. We’re all making mistakes. Also: as we know, there are small mistakes that are almost unnoticeable, and then there are wrong mistakes, that eventually bite you in the behind. And then there are things that feel like mistakes, but actually can be the beginnings of better, more courageous practices. “If people don't want to come out to the ball park, nobody's gonna stop 'em.” Every Agile coach must recognize that, no matter how brilliant your coaching, some people will remain skeptical of Agile. “I wish I had an answer to that, because I'm tired of answering that question.” As with most of these quotes, there are lots of ways of thinking about this one. Here’s one. Imagine you are an Agile coach, and the Team is pestering you with questions about how to do Agile. They will always think of questions to which you have no useful answer. Then you realize: the real point is for them to be able to think it through for themselves. “If you ask me anything I don't know, I'm not going to answer.” And I’m glad you won’t, you might say. But what happens in real life? A developer gets a story and the Product Owner isn’t there. All too often, the developer will make up something that seems to him to be what the story was all about. He didn’t know, but he gave an answer anyway. A common human goof-up. “I knew exactly where it was, I just couldn't find it.” Gosh, we are all so human. We don’t want to admit we goofed-up, we screwed up, we forgot, we spaazed out. So we say something like this quote. Imagine the last day of the iteration, things are tight. You leave late on Friday, and a developer is still in the room, working hard on the last bug. You come in Monday, and you ask about it. He says: “I knew exactly where it was, I just couldn’t find it.” "It's not too far, it just seems like it is." Wherever you are, getting to full Agile can feel like a long way. Your team is almost doing Scrum decently, and you look at that long list of XP practices, and say “oh my”. I’m sympathetic. But it’s not too far, it just seems like it is.


Agile Leadership Should a ScrumMaster lead? There is some controversy about this topic. We certainly do not want the ScrumMaster to be Mr. Command & Control. But is command & control what we mean by leadership? I raised this question on the Scrum Development Yahoo group. Below are two posts by Jeff Sutherland on the subject. Jeff Sutherland is co-inventor of Scrum. I respect him and his most extensive experience with Scrum. Notes: Remember that Scrum was named from the scrum in the Rugby game. Also be aware that Jeff went to West Point, which mixes interestingly with those who own “new age” views on leadership. May this lead you to a fuller understanding of the challenges of leadership for the ScrumMaster, and indeed for all members of the Team and all associated with the project. --- In [email protected], Jeff Sutherland (8/22/05) <jeff.sutherland@...> wrote: You might tell the skeptics that a ScrumMaster is like the quarterback on a football team. Their performance as a company depends on them. A good quarterback is not allowed to play other positions. They might get hurt and disabled. There is a company analogy to this. Of course, a good ScrumMaster is more like a Rugby team captain which they would not understand unless they were Rugby fans. The best Rugby captains are truly heroic and are legends in their time. The fans worship the ground they walk on because their teams win big. They also get paid big bucks. Tell them to get over being a losing company and find a few good ScrumMasters. Jeff Sutherland --- End message --- --- In [email protected], Jeff Sutherland (8/22/05) <jeff.sutherland@c...> wrote: What I experience when working with teams in various companies is that we tell people that the ScrumMaster is a facilitator and has no authority and at the same time the issue for the ScrumMaster is leadership. This is an attempt to break the directive management microcontroller mentality. However, we are often weak in communicating the leadership aspect. A story might help on this. I marched behind General Douglas MacArthur's casket to bury him because I was Training Officer of the company that consistently was the best marching company in the West Point Corps of cadets. As Training Officer I had no authority and before I was put in the job they were one of the worst marching companies in the Corps. All of what I did had to be done through moral suasion and coaching. In the process, I got to know a lot about General MacArthur because he was alive and a force at the Military Academy during all the years I was a cadet. There is a well-known story that during




World War II there was a critical hill in the Pacific Theatre that had to be taken. Several platoons had been sent up the hill and all had been killed. General MacArthur, a five star general and commander of the Pacific Theatre went down to meet the 2nd Lieutenant that had the next platoon that would be sent up to take out the target. He told this most junior of officers that he had complete confidence in him and would give him all the support he knew how to give. He told the 2nd Lieutenant that he knew that it was difficult and that many had died but that he respected the junior officer so much he was going to decorate him before the battle. He took off his own Silver Star from his chest and pinned it on the Lieutenant, saluted, and left the field of battle. (This is exactly how senior Japanese executives set up a Scrum and this example may give you the feeling that the Japanese teams have when given their mission.) The 2nd Lieutenant then talked with the troops and told them how important the mission was, that many had died, but that the General had complete confidence in them, and would give them all the support that he could possibly give to the team to help them. When the time came, the 2nd Lieutenant led the men up the hill. He was the first into hand to hand combat and the team was inspired to follow him. While many died, many survived and they took the field of battle. The great Captains of Rugby teams have the same spirit. They are first into the fray and they take the heaviest blows. Their example inspires the team to higher levels of function. The analogy to the ScrumMaster is that the ScrumMaster must mediate between the team and the other parts of the company, while at the same time making contributions in their field of expertise. They must eliminate impediments and to do so must change company culture. To do this requires leading the charge and taking many blows for the team, particularly from people outside of the team who do not understand what they are doing or have agendas that will undermine team performance. (Always remembering that a dead ScrumMaster is a useless ScrumMaster.) When the team is successful they say the team did it. However, as everyone knows, you don't win the Superbowl without a great quarterback. Yet rarely does the quarterback score the winning touchdown. It is superb offense and defense, running backs and receivers that deliver the bacon. This is the winning spirit of Scrum and if the ScrumMaster is too laid back or uninvolved then performance suffers. It is not to take charge, but to lead the charge once the team has committed to take the field of endeavor. Jeff Sutherland --- End message --- A final comment in an email 2/20/2007 (lightly edited): It is difficult to comment on leadership. At West Point, an institution that has probably devoted more resources to the study of leadership (and produced some great leaders) they have concluded that there is no fixed leadership style. Somehow it is a characteristic of the basic integrity of a person, whoever they may be, and it comes out in different ways for every person. It has something to do with congruence. Congruence of the person with reality that gives those working with that person the inherent sense that what they are doing is the right thing and has a larger meaning that makes it worth some sacrifice whether it be large or small. Truth, transparency, and trust have something to do with it.


Jeff Sutherland --- End message ---


The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals & Interactions over PROCESSES and TOOLS Working Software over COMPREHENSIVE DOCUMENTATION Customer Collaboration over CONTRACT NEGOTIATION Responding to Change over FOLLOWING A PLAN While there is value in the items on the right, we value the items on the left more.

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

© 2001, the above authors

this declaration may be freely copied in any form, but only in its entirety through this notice.


Principles behind the Agile Manifesto A large number of people have subscribed to the manifesto and these principles (first published in 2001). See: http://www.agilemanifesto.org/ We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

http://www.agilemanifesto.org/


What is Agile? For thousands of years the poets have asked great questions. What is love? What is the good? What is truth? What is God? Perhaps “what is Agile?” is not so important a question, but I find it almost as difficult. As we hint in the next section, there are at least 6 different explanations of Agile. Perhaps all of them incomplete. Rather than attempt a short definition of Agile in the beginning of the book, we have demonstrated what Agile is by showing you its Values, Principles and Practices. As a one-sentence definition, perhaps we can accurately say this: Any set of Values, Principles and Practices that is not inconsistent with the Agile Manifesto and the Agile Principles is Agile. The double negative (“not inconsistent”) is my way of letting in non-software projects. In this way, business projects can be agile. In the community these business projects tend to be associated with people and books using the following phrases: Agile Project Management, Extreme Project Management, Radical Project Management, and Adaptive Project Management Agile is like a rope shopping bag (I think these bags originated in South America). The bag holds your project, of almost any size and shape. To hold each project, the bag does not depend on one strand or side of the bag. It depends on the complete flexibility of each strand and part of the bag, as it molds to the very contours of the project. One strand could be cut, and the bag would still hold. A seemingly weak bag, in its adaptability, becomes strong enough to carry a big load. As you mull over these Values, Principles and Practices, consider what makes Agile truly different. You will likely find different answers to that question as you develop and as your projects change.


The Six Blind Men and the Elephant

18 It is with the infinite compassion of Buddha that we approach this great story. This version of the story may be found here: http://www.cs.princeton.edu/~rywang/berkeley/258/parable.html. The picture above may be found here: http://www.jainworld.com/education/stories25.asp A number of disciples went to the Buddha and said, "Sir, there are living here in Savatthi many wandering hermits and scholars who indulge in constant dispute, some saying that the world is infinite and eternal and others that it is finite and not eternal, some saying that the soul dies with the body and others that it lives on forever, and so forth. What, Sir, would you say concerning them?" The Buddha answered, "Once upon a time there was a certain raja who called to his servant and said, 'Come, good fellow, go and gather together in one place all the men of Savatthi who were born blind... and show them an elephant.' 'Very good, sire,' replied the servant, and he did as he was told. He said to the blind men assembled there, 'Here is an elephant,' and to one man he presented the head of the elephant, to another its ears, to another a tusk, to another the trunk, the foot, back, tail, and tuft of the tail, saying to each one that that was the elephant. "When the blind men had felt the elephant, the raja went to each of them and said to each, 'Well, blind man, have you seen the elephant? Tell me, what sort of thing is an elephant?' "Thereupon the men who were presented with the head answered, 'Sire, an elephant is like a pot.' And the men who had observed the ear replied, 'An elephant is like a winnowing basket.' Those who had been presented with a tusk said it was a ploughshare. Those who knew only the trunk said it was a plough; others said the body was a grainery; the foot, a pillar; the back, a mortar; the tail, a pestle, the tuft of the tail, a brush. "Then they began to quarrel, shouting, 'Yes it is!' 'No, it is not!' 'An elephant is not that!' 'Yes, it's like that!' and so on, till they came to blows over the matter. "Brethren, the raja was delighted with the scene. "Just so are these preachers and scholars holding various views blind and unseeing.... In their ignorance they are by nature quarrelsome, wrangling, and disputatious, each maintaining reality is thus and thus." Then the Exalted One rendered this meaning by uttering this verse of uplift,

18 This picture is used by permission from jainworld.com

http://www.cs.princeton.edu/~rywang/berkeley/258/parable.html

http://www.jainworld.com/education/stories25.asp


O how they cling and wrangle, some who claim For preacher and monk the honored name! For, quarreling, each to his view they cling. Such folk see only one side of a thing. Jainism and Buddhism. Udana 68-69: Parable of the Blind Men and the Elephant

* * * Now, I invite you to consider what this story means for you. Consider what different things you would want the elephant to represent. Let’s also look at the story in a positive light. Considering that we are all somewhat blind, imagine how useful it is for all 6 teammates to share information about what the full nature of the project really is.

* * *

Good luck in all your projects.


Resources Books Agile Estimating and Planning. By Mike Cohn. A great book on this subject. And Mike adds lots of tips about how to help a project run better. See: http://www.mountaingoatsoftware.com/books.php Agile Project Management, by Jim Highsmith. More the business side, project management focus on projects. Jim is one of the originators of Agile. Agile Project Management with Scrum. By Ken Schwaber. Largely in the form of stories (patterns), with lessons learned. Many people love this way of learning. See the right side of this page: http://www.controlchaos.com/ Agile Retrospectives: Making Good Teams Great, by Esther Derby & Diana Larsen. Great book on retrospectives. Which are essential to helping the Team reach the next level. Agile Software Development with Scrum. By Ken Schwaber and Mike Beedle. This book takes a different approach to explaining Scrum, which other types of people will like. See especially Jeff Sutherland’s comments in section 1.3.1. Collaboration Explained, by Jean Tabaka. Lots of great ideas on how to facilitate an agile team as it moves toward higher performance. Extreme Programming Explained : Embrace Change (2nd Edition) by Kent Beck and Cynthia Andres. This is one of the definitive books on XP. Extreme Programming Installed by Ron Jeffries, Ann Anderson, Chet Hendrickson, Ronald E. Jeffries. Excellent place to start with XP. Extreme Programming Explored by William Wake. From a practitioner. It is easy to talk, it is harder to do. Extreme Programming Applied: Playing to Win by Auer & Miller. Two more practitioners, out in the wild. Where all new ideas come from. Something of a role model. Extreme Project Management by Doug DeCarlo. Doug explains agile from the business and project leader viewpoint, rather than the developer, tester viewpoint. Lots of discussion of the mindshift that takes place and how to handle the people issues (“projects are people”). Fearless Change: Patterns for Introducing New Ideas, by Mary Lynn Manns & Linda Rising. Great book on introducing new ideas (such as Agile) into a group (from a team to a large organization). You will notice that many of the patterns in this book are embedded in parts of Agile, including some of the parts of Agile discussed here. Getting to Yes by William L. Ury, Roger Fisher & Bruce Patton. Excellent. Simply put. No puttin’ on the dog for the Boston Brahmins or the Council on Foreign Relations. If you think collaboration is hard, try negotiation. Implementing Lean Software Development: From Concept to Cash, by Mary Poppendieck & Tom Poppendieck. Their second book. Lean concepts explain Agile so incredibly well. It is remarkable that Lean (eg, the Toyota Production System) developed mostly independently of

http://www.mountaingoatsoftware.com/books.php

http://www.controlchaos.com/


Agile. The Poppendiecks bring them together. Lean Software Development, by Mary and Tom Poppendieck. Their first book. Lean Thinking by Womack and Jones. Simply excellent. Not directly software related, but highly applicable. Leading with the Heart, by Mike Krzyzewski. Coach K is coach of the Duke Blue Devils basketball team. Perhaps the active coach with the highest winning percentage. Some great ideas on building the team and what leads to success. The Mythical Man-Month by Frederick Brooks. This is the book that started me thinking about Agile, before it was called agile. Such a kind and insightful soul that he can be forgiven for working at a university with colors too pale. Pair Programming Illuminated by Laurie Williams & Robert Kessler. How to make it work, when it might feel awkward. With an economic study if its efficacy. Project Retrospectives, by Norman Kerth. Lots of good insights about doing retrospectives, which, among other things enable continuous improvement. Radical Project Management by Rob Thomsett. I guess one could argue that Rob Thomsett’s book does not assume iterative and incremental delivery. Otherwise, his ideas line up extremely well with the Agile Manifesto. Excellent discussion and exercises for “rapid planning”, which gets projects off to a good start (and can be re-visited later). When he says “planning”, he means more things like alignment of goals and assuring that everyone is seeing the whole project, rather than things like detailed MS project plans. Scrum Checklists by Boris Gloger. Very practical. User Stories Applied For Agile Software Development by Mike Cohn. Great book on using user stories, and other topics related to Scrum and XP. See http://www.mountaingoatsoftware.com/books.php War and Peace by Tolstoy. Leo Tolstoy was extraordinarily insightful about many things. About so many different kinds of people, about how history works, about the unimportance of Napoleon, about the usefulness of Kutuzov, about how work gets done. He could reflect both the wisdom and foolishness of a person in one paragraph. Few have that balance. There is so much to learn here, even about our work. And half is about the development of a series of love relationships. This book for me destroyed the notion that one person plans a war, and the minions just execute the plan. The Wisdom of Teams, by Jon Katzenbach and Douglas Smith. Sometimes you run into a person who thinks individuals are the key to everything. This book provides evidence that teams are actually smarter than one individual. But then, your mother told you that two heads are better than one. Articles “Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams.” By Jeff Sutherland, Anton Viktorov, and Jack Blount. 2006

http://www.mountaingoatsoftware.com/books.php


“The New New Product Development Game” by Takeuchi, H. and I. Nonaka, Harvard Business Review, Jan-Feb 1986 – This is the HBR article that led Schwaber and Sutherland to developing Scrum. “Want Better Software?” By Mike Cohn - An article about what a customer can do if he wants better software. “Extreme Business Value” by Ken Schwaber - A web article about extreme business value and Scrum. See http://www.controlchaos.com/about/value.php “Managing the Development of Large Software Systems” by Dr. Winston W. Royce. Sometimes Agile is presented as the opposite of “the Waterfall methodology”. Dr. Royce’s paper is considered the source of Waterfall. His son, Winston Royce, later implied that Waterfall is dead. Then again, his father had said in this paper that waterfall “is risky and invites failure.” In my opinion, Dr. Royce’s suggestions for improving waterfall start some of the lines of thinking that would eventually lead the Agile group to come up with their proposals later (eg, Involve the Customer). See: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf Web Resources

About Wikis – Well, if you must know more about wikis, start here.

Agile Advice – Here is a nice blog, mainly from Mishkin Berteig, with lots of good advice about, well, agile.

Agile Alliance – The site where the many strands of Agile come together.

Agile Manifesto – Here is the manifesto, and on a link you can also see the Agile Principles. And a description of how the manifesto (not my favorite word) came to be written. We are grateful for the courage of these pioneers.

APLN – Like the Agile Alliance, the Agile Project Leadership Network (APLN) has more emphasis on leadership and managing projects. See the Declaration of Interdependence, which has similarities to the Agile Manifesto. (Declaration has better back-tones to me than Manifesto.)

Brian Marick – Brian has great ideas about testing on an agile project. This is his site. Diana Larsen – Diana has wonderful ideas about making teams more effective, and, again, about Agile Retrospectives. Esther and Diana often work together. This is her blog, called Partnership & Possibilities.

Esther Derby – Esther has excellent ideas about making teams more effective and about Agile Retrospectives. This is her blog.

Jeff Sutherland’s site – Also an excellent source, from the other co-creator of Scrum. Blog format.

Jim Highsmith – Jim Highsmith is one of the originators of the Agile Manifesto. Great thinking about Agile and running projects.

Ken Schwaber’s site – An excellent source from the co-creator of Scrum.

Martin Fowler – Martin Fowler is a very bright guy, with much to say. This is a link to his web article on “the new methodology” (namely, agile). Recently updated. Look around further.

http://www.controlchaos.com/about/value.php

http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf


Mike Cohn’s site – This site has a lot of excellent, practical advice. Very down to earth.

Mike Vizdos – Mike has a nice site called Implementing Scrum. A colleague draws the cartoons, and Mike provides the commentary. The site puts more emphasis on the Chicken and Pig story than I would, but Mike’s ideas and practices are excellent.

Norm Kerth – This man has some great insights on Retrospectives. Here is his Prime Directive, as a start..

Optional Scope Contracts – By Kent Beck and Dave Cleal. Discusses a contract that fixes everything except scope.

The Poppendiecks – Mary and Tom Poppendieck are leaders of Lean Software Development. This comes from the ideas of Lean, Lean Manufacturing, and the Toyota Production System. While developed fairly independently of agile, Lean is remarkably similar.

Rachel Davies – This is her blog. Great ideas, very humanely presented.

Ron Jeffries' site – This is a great site for XP and related Agile advice.

Sanjiv Augustine – Sanjiv has written a book about Agile Project Management, which gets into the ideas that explain agile. This is his site.

Scrum Alliance – The site for Certified ScrumMasters.

Scrum Alliance wiki – This is the unofficial wiki for the Scrum community. Many community resources are available.

Scrum Development Yahoo Group – Where lots of good discussion goes on. You will find posts from the best in the business. Even us.

Scrum Reference Card – There are several like this. This one’s pretty good.

Ward’s Wiki – This is the page on Ward’s Wiki where Ward Cunningham (I think) provides his roadmap to XP. Do look around the wiki. Lots of interesting stuff.

Wikipedia site – This is a site you probably heard about before you knew what a wiki was. Pretty darn good encyclopedia. Great example of a wiki.

WikiWikiWeb – This is the site of the original wiki. Wikis were invented by Ward Cunningham. He and now others have created this site. Ward is an original signer of the Agile Manifesto, among other things. The site is known as WikiWikiWeb or Ward’s Wiki.

William Wake – He has some great information and suggestions. I like his Scrum on one page, for example. He has many other useful ideas.

There are many other excellent resources. I will keep an updated list here: http://agileconsortium.pbwiki.com/Resources

* * *

Future editions (iterations) will modify and add content.

http://agileconsortium.pbwiki.com/Resources


******** To fix: § Add mind map of XP. § Forward from Jeff Sutherland, Mike Cohn, others. § Obtain permission from Andrew McKnight.

elements of agile style ver 0.25agileconsortium.pbworks.com/f/elements of agile style ver... ·...

Documents