Elements of Agile Style ver 0.7 - PBworksagileconsortium.pbworks.com/f/Elements of Agile Style ver 0_7.pdf · The Elements of Agile Style ... Elements of Agile Style ver 0.7.doc 4

Elements of Agile Style ver 0.7.doc 1 of 54 2/22/2007 copyright 2007 Joseph Little

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


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

What this paper intends to be ........................................................................................................... 4 What this paper is not ....................................................................................................................... 5

Thanks and acknowledgements............................................................................................................ 6 Where to start ........................................................................................................................................ 7

Why start with Scrum?...................................................................................................................... 7 Why "the Rules of Scrum"? ............................................................................................................... 7

The Rules of Scrum................................................................................................................................ 9 The Roles in Scrum............................................................................................................................ 9 The artifacts of Scrum ...................................................................................................................... 11 The Story of the Chicken and the Pig...............................................................................................13 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......................................................................................................................................... 22 Sprint Review Meeting ....................................................................................................................24 Sprint Retrospective ........................................................................................................................26

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

General Rules...................................................................................................................................29 Extreme Programming........................................................................................................................30 Values ...................................................................................................................................................30

Humanity .........................................................................................................................................30 Communication ...............................................................................................................................30 Simplicity...........................................................................................................................................31 Feedback............................................................................................................................................31 Courage..............................................................................................................................................31 Respect ............................................................................................................................................. 32

Principles.............................................................................................................................................. 32 Humanity ......................................................................................................................................... 32 Economics ........................................................................................................................................ 33 Mutual Benefit ................................................................................................................................. 33 Self-Similarity ..................................................................................................................................34 Improvement ...................................................................................................................................34 Diversity ...........................................................................................................................................34 Reflection ......................................................................................................................................... 35 Flow .................................................................................................................................................. 35 Opportunity...................................................................................................................................... 35 Redundancy .....................................................................................................................................36 Failure...............................................................................................................................................36 Quality ..............................................................................................................................................36 Baby Steps ........................................................................................................................................36 Accepted Responsibility .................................................................................................................. 37

Primary Practices.................................................................................................................................38 Sit Together......................................................................................................................................38 Whole Team .....................................................................................................................................38 Informative Workspace...................................................................................................................38 Energized Work ...............................................................................................................................39


Pair Programming ...........................................................................................................................39 Stories...............................................................................................................................................40 Weekly Cycle ....................................................................................................................................40 Quarterly Cycle.................................................................................................................................40 Slack.................................................................................................................................................. 41 Ten-Minute Build............................................................................................................................. 41 Continuous Integration ................................................................................................................... 41 Test-First Programming..................................................................................................................42 Incremental Design .........................................................................................................................42 How do we start? .............................................................................................................................43

Corollary Practices...............................................................................................................................44 Real Customer Involvement............................................................................................................44 Incremental Deployment ................................................................................................................44 Team Continuity ..............................................................................................................................44 Shrinking Teams..............................................................................................................................44 Root Cause Analysis......................................................................................................................... 45 Shared Code ..................................................................................................................................... 45 Code and Tests ................................................................................................................................. 45 Single Code Base..............................................................................................................................46 Daily Deployment ............................................................................................................................46 Negotiated Scope Contract..............................................................................................................46 Pay-Per-Use......................................................................................................................................46

Agile Leadership .................................................................................................................................. 47 The Six Blind Men and the Elephant..................................................................................................50 Resources ............................................................................................................................................. 52


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. 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 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.] 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 itself. This is usually a particularly good thing, since you usually have a brand new team or it is doing something brand new. 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 paper 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 paper 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. In the Resources section we have suggested other books. It covers both introductory and more advanced topics. Thank you for doing 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, 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 Davos, Doug Shimp, Stacia Broderick, Bob Schatz, Hubert Smits, Brent Barton, Mary Simone, Stephen Hailey, Prem Balagangadhar, Kim Witchey, Adam Beck, Kelly Snavely, Tariq Bhatti, Mark Hugel, Ryan Scouller, Kara Silva, 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, Guy Beaver, Tom Finnie, Jason Sharpee, Jim Conrad, my friends at KPMG Consulting (now Bearingpoint) 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 (my apologies to those I left out in a senior moment). 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. This book is not worthy of so great a group.


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.

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 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 is 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. Those who have ears to hear, let them hear.

The Roles in Scrum Scrum has three roles: the Product Owner, the Scrum Master 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 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 Team is that group of people who, like the musketeers, have banded together to Git-R-Done 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 the basketball metaphor, the ScrumMaster coaches from the sidelines, while the Team actually plays the game. The Stakeholders do not have a formal role in Scrum. They are looked upon as chickens (see the story of the Chicken and the Pig), and with great caution. The chickens do not have skin in the game, and generally their contribution reflects that. Experience has shown that some are people who make a few useful contributions to the project from time to time. Perhaps they are experts in a


special field. Too many are people who, for good reasons or truly bad ones, suck the energy from the real Team of people committed to getting the project done. Despite good intentions, they tend to interfere with the Team getting the job done. Some obvious advice:

1. 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.

2. 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. Then, try to help them increase their own motivation (Agile will help).


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 to 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 a 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 there way to the tasks they can do in 2 weeks; it feels tight. To them, a month feels loose, like a long time, and they can’t estimate quickly in their head when that time box 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 that he can determine more often whether the Team (and the project) is 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 idea, and an idea 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 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 the 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 may or may not 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 Scrum Master 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 why they mis-communicated and they get the Product corrected.


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.


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 or Team has 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 co-located team, a team room, information radiators, and some of the other primary XP practices. But, as Kent Beck has noted, people will not reach their creative potential if they feel they are forced to do something. 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.


General Rules Team Size: Teams should be 7 people, plus or minus 2. Including the Product Owner, and not including the ScrumMaster in that count. Larger groups should be sub-divided into 2 or more Teams. Scrum includes the "Scrum of Scrums" approach 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 is quite visible to all the interested people. And 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.


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. 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 time-boxed. There are 4 key Scrum meetings: Sprint Planning Meeting Daily Scrum Spring 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. It is sometimes useful to tell recovering Waterfallics that this is where Scrum identifies the equivalent of a detailed project plan. Time-Box: Ken Schwaber calls out a time-box of 8 hours for a month-long Sprint. Obviously, if the Sprint length is less than a month, the time-box should be proportionally less. Thus, a 2-week Sprint would be done within 4 hours. Ken Schwaber also calls out 2 smaller time boxes within the 8 hours. A 4-hour segment to select the Product Backlog 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 time-boxes are sometimes less meaningful. Attendees: The Team, the Product Owner (arguably an integral part of the Team), and the Scrum Master. Additional parties may be invited if they are useful to the Team. There is concern and experience that these other parties are often noisy and useless chickens, 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. In the absence of the Product owner, the Scrum Master may do this (keep the crank churning out something that can be inspected and lead to adaptations, even if not so good). 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 recommended, but not required, that before coming to the Sprint Planning Meeting, each PB item have an estimate that reflects "why we want to do this item" and an estimate of effort (eg, a Story Point number). 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 part of the meeting, 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 most of those specific 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 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 that additional effort must be 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 time-box 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. Second Segment: Immediately the Team starts to take the PB items and break them down into tasks. Again, observe the overall time-box. 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 remain with the Team in this second segment, to answer questions and to 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 Scrum Master 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. And indeed no one person on the Team should dominate in identifying the tasks (such as a former Project Manager). Exactly when higher participation becomes domination can be one of the tougher calls for a Scrum Master to make. Among the factors, the Scrum Master must weigh how much the Team may be demotivated. As indicated earlier, the Team may want to solicit information and advice from others as it creates the task list, and is free to do so. 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. Completeness: Must the Sprint Backlog be absolutely complete 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 time-box. 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 co-located? 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 strongly recommended that all attendees stand-up during the meeting to assure that all feel that as a pressure to be brief. The meeting is meant to be short, and only the most necessary things for the team are discussed. Time Box: 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). 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, including the Product Owner, are required to attend. Every day. Occasional absences of one person or another are not major violations. More frequent absences (or one person or a combination of people) are typically a serious impediment. If a Team member cannot attend in person, he should attend by phone or by having another Team member represent him (ie, 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 Scrum Master 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 Scrum Master 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 only 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 being as effective as possible? Discussion: Team members may, very briefly, discuss what a Team member has said, once she 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(s) should not feel they are answerable to one person, such as the Project Manager). The conversation must be brisk. If some topics require more discussion, that should be called out for after the Daily Scrum…even if the topic is quite important. Focus on the 3 questions; do not digress into issues, designs, problems, or gossip. 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 talk: Any chickens in attendance may not talk, make faces, make observations, or otherwise be obtrusive during the Daily Scrum. Chickens stand on the periphery of the Daily Scrum group (not to be intrusive). Why? Experience has shown that chickens, even 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 time-box during the Daily Scrum. This must not be impeded. If too many chickens want to attend a Daily Scrum, the Scrum Master may limit their attendance so that the meeting is more useful for the Team. (In some circumstances, one chicken could be too many.) Chickens may not intrude after the Daily Scrum. Brief conversations may not be a problem; discussions that the Team wants and initiates are certainly fine. The Team should not feel they must “report” to the chickens. The Team owns the project. This is an area where the Scrum Master must err on the side of protecting the Team. If any chicken who will not conform to the above rules (as interpreted by the Scrum Master), the ScrumMaster must bar them from the Daily Scrum.


The Sprint Time-Box: 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. Abnormal Termination: If the Team cannot complete the Sprint or if the Product Owner wants to change priorities, the current Sprint should be terminated. Then a new Sprint Planning can happen immediately, and a new Sprint begun. This of course means that most of the work of the current Sprint will be lost. The Scrum Master may terminate a Sprint on her 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 Scrum Master 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. Time-Box: 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. (That promised functionality was not completed, the Team must make clear to the PO.) How to deal with this 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, to 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. Using 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 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 doing the demo of the software and discussing the results. 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 Time-Box: 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. However, once the Time Box 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 upon information that will help them get better. Typically a retrospective should lead to specific actions to improve things. 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 normal 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)

Often the SM will need to ask that each person give at least one Plus and one Delta. (This and other techniques are used with less-talkative team members.) Summarize: The SM will write down the Pluses and Deltas in summary form. Analyze & Prioritize: The Team 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 Team's 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 the managing of 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. 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 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 change get a fair hearing from the whole Team.

Alternative Approaches Using the standard approach can work well for several iterations, but most Teams benefit from adding variety to this standard approach. Thus, different exercises may be used generate information at the beginning of the Retrospective, etc, etc. See Resources for further information. Otherwise, the same basic rules mentioned above still apply.


Derby and Larsen recommend a five step agenda for every Retrospective. • Set the Stage • Gather Data (one of quite of number of possible exercises) • Generate Insights • Decide What to Do • Close the Retrospective


General Rules For Chickens who will not conform to the above rules (as interpreted by the Scrum Master), the Scrum Master must bar them from the related meeting (eg, the Daily Scrum). If any pig will not conform to the above rules (as interpreted by the Scrum Master), the Scrum Master must get them removed from the Team. While these are an extreme measures, they must be used occasionally. On Time-Boxes: The time-box 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-saving, is usually the wish to hide some information from someone. On the other hand, we support strongly those who insist that each meeting stay within the time-boxes mentioned above.

* * * To those who want to play only part of Scrum, our reaction is much like we would have to those who wanted to play only part of baseball. It might be an interesting game, certainly novel. But it is probably ill founded, likely silly, and certainly not Scrum.


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. 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. Values In this book, we will talk about values in several contexts. 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 most of Agile, whether we are doing it right is a key issue.

Humanity Kent Beck includes Humanity as a principle of XP and not as a value. 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.

I would include Humanity as a value as well. To me, Agile’s first values relate to people. To the customer, 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 people. 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 asked for today. Less to figure out later. Less to be pretentious about. One famous agile phrase is: Do the simplest thing that could possibly work, and then test. Of course, this value of simplicity fits with that.

Feedback Feedback means doing something that gives us information. Then we analyze that information. We form some idea of 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. 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 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. 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. Courage is of course different than foolhardiness. Don’t just do something because it would be 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 (to trust that the Team will produce good software after a poor effort in the prior iteration) 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. 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.

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 – The need to accomplish some meaning 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 their full individuality. At the same time 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.

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. Usually best to do those 20% 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, to 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, to achieve satisfaction for other customers, or for other uses by the same customer.

Mutual Benefit Beck: “Every activity should benefit all concerned.” And 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. And life is not always that convenient. However, his practical applications are quite reasonable. 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 mainly about people.) Extensive internal documentation of software is an example of violating mutual benefit. Beck offers several alternatives that solve the same problems while being beneficial to all.


Self-Similarity Beck is really talking about patterns here. We should follow organic patterns. So, if this world is like the macrocosm and the microcosm, so we probably are safe to consider whether normal patterns can be replicate in the larger project, or in the smaller, minute-by-minute work. Consider copying the structure of one solution to use as the solution in a different context. Not unthinkingly, but considering “what can I copy directly, what must I modify some, and what should I not use”. One set of patterns is the rhythms people have in various activities. 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.

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; if you are honest 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 fall-out from 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 would 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 differences of view about what the problem is. So we can see the problem more fully and more clearly. We need differences of view about solutions, so that, from consideration of the options, we can find the better option (perhaps not either of the three initially proposed). No one should be following the lead of someone else “because”. Where “because” is followed with any number of unless 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. In Waterfall, we identify discrete things to work on in each phrase (eg requirements, design, coding, testing, etc, 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 to delivery to be in as small a “batch” size as possible, contrary to our human tendency under stress. Weekly deployment is preferred as it provides more flow (and more feedback).

Opportunity “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. Beck mentions quarterly long term planning and pair programming. Don’t be discouraged or slowed down by problems. They are normal. Choose carefully the most useful ones to improve with.


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. “Defects corrode trust and trust is the great waste eliminator.” 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. So 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.) Faster than analysis paralysis. This is very different than sloppy thinking or poor execution. No excuse for that. This is failure 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 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. 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. It is better to take two baby steps forward, than to take one big step forward, recoil, and take two 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: Use the principle 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 meet the needs for privacy. Communicate with all your senses. The common space enables many things, including a sense of team common 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.

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. Usually that workspace involves mainly the walls in the team room. 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 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 not 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. But hard to see you are doing it. 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. 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 for a year. Pairing does not mean that an experienced 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 groups to two. Perhaps some things should be reviewed 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.


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.) 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 minivan for $25,000. Until we see the cost, many of us might prefer the Ferrari. 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”. 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. I and others prefer to start the week or the iteration on a Monday. So that the Team does not work weekends. Because it is a natural rhythm. But it is not critical to start on Monday. 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.

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 it would typically have a release at least every two months. But I like the idea of having a 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 (beyond the next release) that it adds no value to think about yet. 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 so that you can drop some tasks and still make your major commitments (of the iteration). Beck’s main argument for this is that trust is precious, and generally lacking. So, you need slack to build up that trust that evolves for keeping the commitments the team makes. Very important. Beck also mentioned the incredible waste generated from over-commitments. 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. Notice that 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 build 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 there today, where do you start?

1. Start by building just part of the system automatically. 2. Then build the whole system automatically. 3. Then tune the build so it can happen in less than 10 seconds. 4. Then add a bunch of automated tests (the most important ones). 5. 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.” Some of the new IDEs (Integrated Development Environments) do actual builds in real time. This is going a step further and integrating with the whole system. And running all the tests. In 10 minutes. Why? We want fast feedback to the developers, if there are any errors or regression errors. This allows they 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 be all the way to the end. You find out about every possible problem in the deployment as soon as possible.

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, and induces a good rhythm (and 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 environment won’t accept 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.

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. 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 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. Or the design issue (eg, to support functions in release 2) should not be paid for in release 1 (but in release 2). If you have a big design question where an answer does not appear quickly, consider attacking that problem by tying 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? Have you eliminated all the duplication?

How do we start? We already suggested starting with Scrum. In our ideal scenario, you would start with Scrum and some of the basics of XP (eg, the whole team, a customer or Product Owner, 2-week Sprints, stories for PB items, sitting together, an informative workspace, and energized work. And maybe some pairing (a common-sense thing that almost everyone does to some degree). Then start experimenting by adding additional practices. I’d start with test-first programming. Then 10-minute builds. And then incremental design. Don’t expect each of these XP practices to come easily to you. Give it time and it will pay benefits. If you find something isn’t working well, consider reverting for a time to your old practice. Probably other things new to be more solid before this new XP practice can help you.


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 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? Becks 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 always remain completely static. Ask one person to move from this team to that team, because it’s needed. And 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 four more whys. And then one fixes all five causes along the way. 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. Otherwise, the ability to fix things quickly, and the reduction of reliance on any one person, these obviously are good. And it obviously is good in the sense that 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 likely the code is more 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: 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 excess page of paper gets in the way of the usable information in any documentation. Using Pareto, 80% of current software documentation is probably waste in terms of the best use of those resources needed to create that documentation. Use continuous improvement to have the Team continually eliminate or reduce documentation


that isn’t clearly lots 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, etc. 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

Negotiated Scope Contract

Pay-Per-Use


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

mailto:[email protected]

mailto:[email protected]


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 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, particular 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 and running backs 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 Six Blind Men and the Elephant

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 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, O how they cling and wrangle, some who claim For preacher and monk the honored name!

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


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 may mean. Consider what different things you would want the elephant to represent. Good luck in all your projects.


Resources Books 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/ 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 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 the Jeff Sutherland’s comments in section 1.3.1. Extreme Programming Explained : Embrace Change (2nd Edition) by Kent Beck and Cynthia Andres. This is one of the definitive books on XP. Lean Software Development, by Mary and Tom Poppendieck. Their first book. 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 Agile. The Poppendiecks bring them together. Agile Project Management, by Jim Highsmith. More the business side, project management focus on projects. 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 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. Project Retrospectives, by Norman Kerth. Lots of good insights about doing retrospectives, which, among other things enable continuous improvement. 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. 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). Collaboration Explained, by Jean Tabaka. Lots of great ideas on how to facilitate an agile team into higher performance. Leading with the Heart, by Mike Krzyzewski. Coach K is coach of the Duke Blue Devils basketball

http://www.controlchaos.com/

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

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


team. Perhaps the active coach with the highest winning percentage. Some great ideas on building the team and what leads to success. 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. Articles “Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams.” By Jeff Sutherland, Anton Viktorov, and Jack Blount. 2006 “The New New Product Development Game” by Takeuchi, H. and I. Nonaka, Harvard Business Review, Jan-Feb 1986 – This is the famous HBR article that caused Schwaber and Sutherland to name it “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 To be added.

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

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


* * * Future editions (iterations) will modify and add content.

Documents

Elements of Agile Style ver 0.7 - PBworksagileconsortium.pbworks.com/f/Elements of Agile Style ver 0_7.pdf · The Elements of Agile Style ... Elements of Agile Style ver 0.7.doc 4