ࡱ> M  bjbj== lWW!\;l:#:#:#:####T$0B0B0BBCt$d,D4LLLLLeOSUW d d d d d d d$f hL1d#WO^eOWW1dma:#:#LL_FdmamamaW:#RL(#L dmaW dma<maac#"# dL D ?$.0BYHc d\d0ddi]i dma$$:#:#:#:#  Agile Style Software Development A personal and slightly frivolous survey With a loose emphasis on problems and solutions   EMBED Package  Table of Contents  TOC \o "1-9" \t "Heading 9;9;Heading 8;8;Heading 7;7;Heading 6;6;Heading 5;5;Heading 4;4;Heading 3;3;Heading 2;2;Heading 1;1;Heading 1;1;Heading 2;2;Heading 3;3;Heading 4;4;Heading 5;5;Heading 6;6;Heading 7;7;Heading 8;8;Heading 9;9" \h HYPERLINK \l "_Toc203227608" 1 Introduction  PAGEREF _Toc203227608 \h 4  HYPERLINK \l "_Toc203227609" 1.1 Sex  PAGEREF _Toc203227609 \h 5  HYPERLINK \l "_Toc203227610" 1.2 Superiority In A Nutshell  PAGEREF _Toc203227610 \h 5  HYPERLINK \l "_Toc203227611" 2 Dont Learn From History!  PAGEREF _Toc203227611 \h 6  HYPERLINK \l "_Toc203227612" 2.1 Is software so different?  PAGEREF _Toc203227612 \h 6  HYPERLINK \l "_Toc203227613" 2.2 How does this become a problem?  PAGEREF _Toc203227613 \h 7  HYPERLINK \l "_Toc203227614" 2.3 How about remedies  PAGEREF _Toc203227614 \h 7  HYPERLINK \l "_Toc203227615" 3 Anti-process  PAGEREF _Toc203227615 \h 8  HYPERLINK \l "_Toc203227616" 3.1 Planning and tracking  PAGEREF _Toc203227616 \h 8  HYPERLINK \l "_Toc203227617" 3.2 Abdicates Responsibility for Requirements Capture  PAGEREF _Toc203227617 \h 9  HYPERLINK \l "_Toc203227618" 3.3 Abdicates Responsibility for Design  PAGEREF _Toc203227618 \h 10  HYPERLINK \l "_Toc203227619" 4 Change = drift, anarchy, slippage  PAGEREF _Toc203227619 \h 11  HYPERLINK \l "_Toc203227620" 4.1 Change is OK culture  PAGEREF _Toc203227620 \h 11  HYPERLINK \l "_Toc203227621" 4.2 Is it slippage?  PAGEREF _Toc203227621 \h 11  HYPERLINK \l "_Toc203227622" 4.3 We can cope with change, but only if we try  PAGEREF _Toc203227622 \h 12  HYPERLINK \l "_Toc203227623" 5 Build Nirvana  PAGEREF _Toc203227623 \h 13  HYPERLINK \l "_Toc203227624" 6 Culture Change Icebergs  PAGEREF _Toc203227624 \h 13  HYPERLINK \l "_Toc203227625" 7 We Have a Process Who Needs Judgment?  PAGEREF _Toc203227625 \h 14  HYPERLINK \l "_Toc203227626" 8 Dont take it literally for goodness sake!  PAGEREF _Toc203227626 \h 14  HYPERLINK \l "_Toc203227627" 9 Commercial misfit  PAGEREF _Toc203227627 \h 15  HYPERLINK \l "_Toc203227628" 9.1 The dilemma  PAGEREF _Toc203227628 \h 15  HYPERLINK \l "_Toc203227629" 9.2 Goodwill  PAGEREF _Toc203227629 \h 15  HYPERLINK \l "_Toc203227630" 9.3 Chalk and Cheese  PAGEREF _Toc203227630 \h 16  HYPERLINK \l "_Toc203227631" 9.4 Tactics?  PAGEREF _Toc203227631 \h 16  HYPERLINK \l "_Toc203227632" 10 Infancy  PAGEREF _Toc203227632 \h 17  HYPERLINK \l "_Toc203227633" 10.1 The dilemma  PAGEREF _Toc203227633 \h 17  HYPERLINK \l "_Toc203227634" 10.2 Analysis  PAGEREF _Toc203227634 \h 17  HYPERLINK \l "_Toc203227635" 10.3 So how do we start then?  PAGEREF _Toc203227635 \h 17  HYPERLINK \l "_Toc203227636" 11 Reverse gear  PAGEREF _Toc203227636 \h 18  HYPERLINK \l "_Toc203227637" 11.1 How do we get backward steps?  PAGEREF _Toc203227637 \h 18  HYPERLINK \l "_Toc203227638" 11.2 How do we agree on what to do?  PAGEREF _Toc203227638 \h 18  HYPERLINK \l "_Toc203227639" 12 Pressure and Expediency  PAGEREF _Toc203227639 \h 18  HYPERLINK \l "_Toc203227640" 12.1 Developers voice  PAGEREF _Toc203227640 \h 19  HYPERLINK \l "_Toc203227641" 12.2 Strain and Heroism  PAGEREF _Toc203227641 \h 19  HYPERLINK \l "_Toc203227642" 13 Hiatus and Minor Crisis  PAGEREF _Toc203227642 \h 20  HYPERLINK \l "_Toc203227643" 13.1 Large refactor dilemma  PAGEREF _Toc203227643 \h 20  HYPERLINK \l "_Toc203227644" 13.2 Cave in?  PAGEREF _Toc203227644 \h 20  HYPERLINK \l "_Toc203227645" 13.3 Surrogate customer  PAGEREF _Toc203227645 \h 21  HYPERLINK \l "_Toc203227646" 13.4 Post mortem  PAGEREF _Toc203227646 \h 21  HYPERLINK \l "_Toc203227647" 14 Snappy Turnaround  PAGEREF _Toc203227647 \h 22  HYPERLINK \l "_Toc203227648" 14.1 Difficulty  PAGEREF _Toc203227648 \h 22  HYPERLINK \l "_Toc203227649" 14.2 Response  PAGEREF _Toc203227649 \h 22  HYPERLINK \l "_Toc203227650" 15 Delinquent Customer  PAGEREF _Toc203227650 \h 23  HYPERLINK \l "_Toc203227651" 15.1 Digression  PAGEREF _Toc203227651 \h 23  HYPERLINK \l "_Toc203227652" 15.2 Agile Customers  PAGEREF _Toc203227652 \h 23  HYPERLINK \l "_Toc203227653" 15.3 Excessively Good Customer  PAGEREF _Toc203227653 \h 24  HYPERLINK \l "_Toc203227654" 16 Knowing When To Stop Part 1  PAGEREF _Toc203227654 \h 24  HYPERLINK \l "_Toc203227655" 16.1 Stopping a waterfall  PAGEREF _Toc203227655 \h 24  HYPERLINK \l "_Toc203227656" 16.2 Stopping with Agility  PAGEREF _Toc203227656 \h 25  HYPERLINK \l "_Toc203227657" 17 Knowing When to Stop Part 2  PAGEREF _Toc203227657 \h 26  HYPERLINK \l "_Toc203227658" 17.1 A Fantasy  PAGEREF _Toc203227658 \h 26  HYPERLINK \l "_Toc203227659" 17.2 The Reality Problem  PAGEREF _Toc203227659 \h 26  HYPERLINK \l "_Toc203227660" 17.3 Remedies  PAGEREF _Toc203227660 \h 27  HYPERLINK \l "_Toc203227661" 18 Disagree  PAGEREF _Toc203227661 \h 27  Introduction This article distills some observations I have made about managing the development of software over 20 years or so. This period has seen a seismic and painful learning process for practitioners and the software industry. My judgement is that the Agile oriented ideas offer the best packaged strategy and philosophy thus far, and these have been a significant influence on my work. There is no shortage of reference material and advocacy for Agile and related approaches from very respectable and scholarly sources. This article is not an alternative to these. It assumes you have a level of prior knowledge. Instead, it is an informal, personal survey of my experience trying to put various elements of it into day-to-day practice. I have aimed for a rough theme of problems and solutions, but have also digressed willfully in places. My target audience is the people who carry some management responsibility for getting software developed. This includes senior developers, project managers, development managers and team leaders. An admission If any of the developers I have worked with read this they could be forgiven for accusing me of hypocrisy. If you think these problem remedies work why the hell havent you implemented all of them! I offer three defenses. First, I have implemented most of them. Second, software development managers cannot spend all their time introducing process improvement we have to make priority calls among all our other responsibilities. And third the writing of this article was a deliberate and fresh endeavour to characterise and marshal some of the problems and to think anew about solutions. Hence some of the ideas are freshly minted. If you are working with me right now look out! I cant tell how generally applicable my experience is. It may help you to know the contexts in which Ive formed these views. I have served a variety of industries and types of organisation, but the common theme has been software development for a highly technical problem domain. E.g. Mechanical CAD/CAM, embedded Linux networked appliances, chip design tools, intelligent electro-mechanical machines, and aerodynamics. The organisation sizes have varied from 80,000 employees down to about 20. It has involved standard products sold in volume, to one-off deals with very large IT OEMs, to tool development for internal departments. Ive reported to CEOs in smaller companies where resources are limited but you can make big things happen easily and fast, but also in very large companies where money is relatively abundant, but change is only achievable infrequently and on geological time scales. Ive assassinated traditional development lifecycles pretty unequivocally in this article which is perhaps silly and unfair. Please take it as poetic license to make a more entertaining polemic. Sex Are developers and customers men or women? Should I call them he or she? I could be really careful to alternate. Or I could always use she to pretend that Im right-on and politically correct. But Im not. Im going to use he because the real developers and customers I have worked with have been male predominantly (hello to Kirsty, Kate, Ivonna, Carren, Angela and Anna who are the only exceptions that come immediately to mind) . I have also tended to use the term sides quite a lot to describe either the development people, or the customer people. Its perhaps an imperfect term as it can imply adversity, but Im not implying that. Ok? Superiority In A Nutshell While my focus will be problems and remedies, Id like to condense my personal reasons for using Agile development methods. It provides a backdrop. It is absolutely impossible for developers and customers to obtain a sufficient grasp of requirements at the outset of a development. Theres no point in debating the truth, or causes of this; experience makes it irrefutable. If you wont accept this position, there are more valuable uses to which you can put the following 26 sheets of paper than reading them. If our lifecycle imparts credibility and authority to the requirements we froze when we started, they quickly become very obviously discredited, and often the culture of this lifecycle is to disparage significant changes to the requirements. This is software engineerings equivalent to shooting yourself in the foot. We are increasingly and continuously able to assimilate our requirements as we begin to see the emerging development. This is because abstract and difficult concepts give way to concrete software which effortlessly and quickly reveals shortcomings, misunderstandings, and mistaken assumptions. It follows that we will change our minds as we go; for well-judged, legitimate reasons. These changes of mind are valuable for all parties and must be exploited if value is to be created. Agile methods encourage this. Working software, delivered at frequent intervals is infinitely more effective as a communication, tracking and feedback instrument than documents and reviews. After all, this is the currency that really counts. We get zero ambiguity and zero peripheral effort expended. Working software, delivered at frequent intervals is also the best way to mitigate risks. The potential for nasty surprises is greatly reduced, and when they do come we are much better able to cope, because we have a methodology that embraces frequent change. And we discover these things earlier when their impact is less. We create customer buy-in and a collaborative ethos as a side effect. We avoid an adversarial acceptance-testing phase at the end almost completely because it is patently unnecessary when the customer has been using and steering the development at every step of the way. The method makes time-boxed, or budget-boxed development perfectly reasonable and practical. With careful engagement by the customer we produce at the end of our time or money the best solution that was possible within the constraints AND quality does not suffer in the way it tends to with a time-pressured linear lifecycle. We tend to achieve much higher quality. Partly because of the regimes we put in place to make rapid change viable, partly because we are getting good feedback from the customer all the way along, and partly because we have to attend to quality issues continuously and routinely, rather than in a rush at the end. Dont Learn From History! Is software so different? Among the engineering disciplines, software is the new kid on the block. We started to develop software with scant attention to lifecycle and software engineering concepts. When you had to load your compiler from paper tape, scrum meetings would perhaps not have been seen as too relevant! As the industry evolved we figured that some process discipline might be a good idea and we naturally borrowed most of the concepts from the other engineering disciplines. This was probably the most serious mistake we made and we are still suffering from it. What? Surely we have in common that we conceive something, we design it first architecturally and then in detail. Then we build prototypes, we test and ultimately we reproduce it in whatever quantity is required? Yes but the similarity is skin-deep and masks what are much more significant DIFFERENCES. Here are two: In the other engineering disciplines, the cost and effort of design is tiny in comparison with manufacturing or production. The traditional engineering approaches have therefore quite properly emphasised a big emphasis on design to mitigate cost and effort in the later stages. The opposite is true of software. The design phase (which includes coding) is where ALL the cost is; to all intents and purposes. Our manufacturing is almost free. In the other engineering disciplines it simply isnt viable to make large numbers of experimental versions and variants. Just imagine how useful it would be if you could knock up experimental variants of your aircraft carrier every few days and then throw them away. Thats what we take for granted with software. If I have a software development team of 10 people, they will each very often make fully working personal variants as often as every ten minutes. Thats one new variant every minute of every day to try out and then throw away. These two differences alone tell us that we should maybe look for different methods for software development. How does this become a problem? The reason this can be a problem, is because the industry is still full of people who havent woken up and smelled this particular cup of coffee. We still have respected methodologies like Prince2 that enshrine the traditional methods even though experienced people know deep down that these seldom produce truly valuable software. They can create the illusion of success because their discipline means that someone can prove they delivered what they promised at the beginning. Customers are reluctant to admit that what they asked for, was in hindsight, rather a poor match with what they now realise they needed. The last time I looked at the ISO standards and TickIT (which was admittedly a while ago) they too endorsed waterfall lifecycle development. The most common approach to sub-contracting development is to require quotations and estimating against specifications which are then extremely difficult to change once contracts have been placed. How about remedies The particular problem this section is trying to remedy is resistance to using Agile methods. The first question to ask yourself, is are you trying to introduce it seriously and professionally, or are you just bleating, without making a serious effort? You need to look at it as a serious management decision making process that will (and should) be held up to scrutiny. The objections people will have are usually entirely reasonable objections to perceived, or actual risk. Work has to be done to deal with these concerns. What can you do to make sure your dissenters are properly educated about the topic? There are plenty of serious advocacy web sites have you offered to present a workshop / review to look at how it could work in your organisation / context? Introduction / survey:  HYPERLINK "http://en.wikipedia.org/wiki/Agile_software_development"http://en.wikipedia.org/wiki/Agile_software_development Advocacy from the pioneers:  HYPERLINK "http://agilemanifesto.org/"http://agilemanifesto.org/ A kind of professional club (non-profit):  HYPERLINK "http://www.agilealliance.org/"http://www.agilealliance.org/ Have you any credible evidence of its success elsewhere in your organisation? If so find your dissenters counterpart in the other project and seek his advocacy. Dont expect a push over, or try to change everything overnight. Can you find a smaller, lower risk project to warm up on? There are tactics you can adopt if you are compelled to use traditional lifecycle methods. Dont forget these methods always have provision for changing requirements. Admittedly these are often viewed as exceptions rather than the norm and are often perceived as a symptom of failure. However see if during the coding phase of the traditional lifecycle you can persuade your customer to collaborate with you and take delivery of iterative developments then one thing is sure both sides will quickly see compelling opportunities to change the requirements and you will have powerful evidence that this would make a good decision for both sides. The traditional lifecycles would often make people respond to this with conflict, but it neednt. If both the supply and consumer side can present a unified front in making the case for the changed requirements and enter into the spirit of the change control process in the traditional lifecycle you will be in effect demonstrating the value of the iterative approach, and the detractors will notice the pattern. If you try this, you must do it properly and produce production-quality iterations and not lash-up prototypes which means proper automated unit testing. You cant fudge this. If you deliver frequent iterations that are of poor quality you are making the case for the opposition! If you hit a wall of resistance with your formal outward facing projects, then is there a smaller, maybe internal project that you can use to demonstrate how well it can work in a scenario with less risk? Anti-process Agile methods are sometimes perceived to be anti-process. This is sort of true and not true at the same time. For this reason, we shouldnt be surprised that people will suspect it of being cavalier or an abdication of responsibility. We need to look at the detail. Planning and tracking We need a process whether we like it or not to expose our development progress for scrutiny. This is entirely reasonable. The traditional approach is to try to predict what development work chunks should be done in what order, and how long they should take. We then assign them to our software engineers and produce a document detailing these predictions. The progress tracking process then is to scrutinise at intervals if the work is unfolding according the predictions on the documented plan. This is ostensibly a perfectly sensible approach, but it has serious flaws that Agile processes solve. The first flaw is that the development doesnt unfold according to the plan. EVER. Well that is not quite true there are two exceptions. The first is theoretical, and is when the requirements capture and high level design are executed absolutely perfectly. Im waiting to witness this phenomenon, it might happen one day. The second exception is quite common, but is a tragedy. This is when the process FORCES people to follow the plan. It may not be explicit this strong handing it is just as often a cultural position that says succeeding in adhering the plan is of pivotal importance. This is crazy but common. Heads will roll or at least cards will be marked if the project manager or team leader cannot adhere to the plan. So we follow the plan and deliver what we promised at the beginning. Brilliant. Measurably perfect performance, delivering junk. This attitude is in denial of the fact that a schedule is the best judgment that can be made today about how things will unfold, given the information that is available today. But new information emerges each and every day. We all know that when the customer is allowed to get his hands on the software, a plethora of things will crop up that make changes desirable to everyone. So who had the big idea that A) this should be deferred until the end of development, and B) that change should be avoided when possible? The Agile process makes frequent deliveries of working software THE measure of progress. In a sense it is anti-process because we are advocating an instrument that is not a document, and we are offering something that cannot be scrutinised against a baseline agreed at the beginning. But it is a process in the sense that it is documented in the form of iteration goals. I think it is a better measure of progress than a document because A) it is tangible and completely unambiguous, and B) the customer is an embedded part of the status reporting process providing an un-biased and more meaningful picture. EVEN if you think it is a less satisfactory measure of progress than traditional methods surely a method that helps you produce software that is highly fit for purpose using the optimal developmental route is a more important dimension? Abdicates Responsibility for Requirements Capture Oh no it doesnt! cried the audience. You should always do a serious requirements capture exercise at the beginning of a development project. This is not in conflict with Agile one jot. The difference is what happens next. In Agile, the initial requirements capture is seen as a vital guiding light. It is assumed and accepted that it will be WRONG in possibly many ways because neither the developers or the customer are capable of getting them complete or accurate at the beginning. This isnt because we are afflicted with dumb developers or customers. It is because it is impossible. We learn SO MUCH from seeing the software evolve and being used in its preliminary stages by real users in comparison with what we knew at the beginning that we inevitably bring new perspectives to the requirements, and many of the explicit and implicit assumptions we make are shown to be wrong. Much of what we thought was important is revealed not to be. Much of the stuff we didnt even think about at all turns out to be vital. So how is this a problem? Well its not with full blown Agile, but can be if you are trying to introduce it into a sceptical culture. Traditional lifecycles will impose a change management regime on requirements that carries significant admin overhead and makes it unpopular and resisted. Agile on the other hand sees each change as a ratchet-click in the direction of making the software better for the customer and in fact a cause for celebration. Remedies? The first thing to try is education. Try to show people that the admin overhead of formalised change management on the requirements specification is unwarranted and unnecessary and may lead to a reluctance to change which equals an enthusiasm for keeping the software rotten for the customer. You need the customer to advocate this position alongside you. People will be anxious that the changing requirements will lead to drift, anarchy and schedule slip. You need to address these questions. See later sections. If you cant get support for this, at least champion the necessity for changes and accept the change management process you cannot in all good faith drop back to delivering what you promised arbitrarily knowing that is the wrong solution for the customer. Abdicates Responsibility for Design This is another fallacy. You must design. In fact Agile places very high expectations on design. There are two new points of emphasis to design however introduced by Agile. The first of these is a policy not to over-design. Software engineers have traditionally been encouraged to design to accommodate a multitude of unseen future, possible scenarios wherever possible. This has historically been seen as good practice because it just might avoid the need for future changes. This makes sense with the old change is the enemy culture, but with Agile, we can do better by gearing up for good change. Agile says you should design extremely carefully but only in order to satisfy the requirements of the current iteration. One reason for this is that it reduces complexity which is always good. Another is that is reduces the test burden. (see testing later). Another is that it focuses effort on what the entire development/customer collaboration has decided is most important. Finally Agile accepts (and copes with) future change - when it is the right thing to do, so we neednt waste time and effort on code that might never be needed. (A minor digression to say that code that is not in active use is a liability not an asset. It creates a kind of noise, and if no-one is using it we have no idea if it is any good.) The second Agile emphasis is designing your software to make it amenable to change. Which of course is always good, not just with Agile. It is particularly important with Agile. The key tenets of design that can help with this are de-coupling and making sure design elements have only a single, clear role. Using relevant design patterns where appropriate is an extremely valuable tool to achieve the former. My final word on how you should design in an Agile development context, is about common sense. These are not rules, they are guidelines which must be applied with judgment. For example if you know with complete confidence that your design will need to cope with , but the current iteration does not include this yet, then of course take this into account and dont bury your head in the sand. But where possible, come up with a design that is readily extensible later to incorporate but dont necessarily include it now. For example, if you are fetching some input data, and the current iteration says that will be from a the local file system, but later on it may be from a database or a network service then you come up with the file system design only, but make sure you dont include paradigms that wont map onto the alternatives like deducing something from the filename, or its timestamp. All object oriented languages let you specify interfaces as part of your design in one way or another, so why not express your future-proofing using an interface, and then implement only the single implementation required by the current iteration. Change = drift, anarchy, slippage If you observe frequent and significant change in the context of a waterfall development lifecycle, then yes, your project is almost certainly heading for the long grass. So we have evolved this culture of treating change as the enemy and we often try to avoid it or hide it, or we have conflicts over it. Agile starts from a different position. We accept that despite our best efforts, we will have compelling and legitimate reasons for wanting change as we proceed. We recognise that this causes potential complications and that we must deal with these. This section deals with some of the steps we must take BEFORE we can celebrate change as an opportunity because we have proper coping mechanisms. Change is OK culture This is the soft / people side of the equation. If we are introducing Agile, we must recognise that a culture change is necessary, and culture changes take management time and effort. In Agiles case it is mostly education. In the particular case of change being ok our customers will be the main instigators, and so they usually accept the benefit and not see any problem. The attitudinal change is needed more among the development team and with distant and remote management. Developers must be educated that sometimes their software will need to be re-written, sometimes several times. Sometimes even ditched completely. This takes some getting used to, and can cause resentment in the absence of support and education. Why cant they work out what they want and tell us? You can usually stimulate some empathy on the developer side by asking why cant you always design your code right first time? you often want with the benefit of hindsight to go back and do it again. Distant management can be discomforted by signs of frequent change because in the absence of detailed knowledge of your new modus operandi they quite reasonably see it as a bad sign. You have to put effort into education in this direction. Make sure you and your customer present a united front, and realise that this is part of the management job of introducing Agile. Is it slippage? Tricky one that. Slippage is usually viewed as retreating forecasts for delivering things. Delivering stuff late is a very bad thing to do and usually causes customers immense difficulties. We must strenuously avoid it. Agile doesnt have a magic solution to this challenge, but it does have some answers. Firstly, we have consistently high quality aspirations from day one. Everything we deliver no matter how limited in function is of full, production quality. (See testing later). Secondly the customer knows intimately at every stage what the software can and cannot do, and may be using it in earnest quite early on, with limited functionality. This means that if push comes to shove and we need to deploy it before the all the desired features are ready we at least have a perfectly viable product in all other respects, and have the choice to release a feature-poor version on time. One way to increase the probability of delivering on time is to make sure we have the most optimum, focused and tuned development trajectory we can. The customer drive we get from Agile places us very much closer to this trajectory than alternatives. We can avoid completely some work that we discover is no longer sensible as we go. In fact we can guarantee that all the developments we do are THE most important things that can be worked on taking into account the very latest information. In my experience, Agile helps to achieve deadlines, with the main reason being that the customer is a central part of the partnership that is trying to achieve this. It produces very well informed compromises and priority setting in the best interests of both sides. We can cope with change, but only if we try You simply cannot cope with frequent changes in development without some serious provision for some of the issues that arise. If you try to do Agile without these you will fail. Your code base must be predicated on very high standards of design. If you havent taken code de-coupling very seriously and carefully designed the boundaries for classes / modules etc, then you are going to feel great pain trying to change your code frequently. It will be intellectually much more difficult. Fewer of your people will be capable of doing it. It will be more error prone and risky. And it will take too long. If you are working with a non-trivial code base that isnt designed pretty well dont try Agile without accepting substantial re-factoring as an integral part of it. You must have automated testing. Again, it simply isnt viable to change code on the scale and frequency expected by Agile if you have to test it by hand. And you certainly cant skip the testing either or your customer will soon lose his enthusiasm for taking frequent deliveries. You must make it practical and efficient for developers to work concurrently on changes and to be able to communicate efficiently and readily. As far as support systems are concerned this means a respectable source code control system with minimal obstacles to developers working on their own branches, and minimal bureaucracy connected with check-ins. Plus a defect tracking system that everyone is persuaded to use routinely. Build Nirvana Agile places new requirements on build systems. If you deliver releases only infrequently there may be insufficient return on investment to make a slick build system. With Agile, you cannot make do with anything less than 'build nirvana'. Your releases are of a frequency that your build must be painless and highly efficient. It must be automated. Try to build at least every night. Better still use a system that kicks of an automatic build every time the source code repository changes. (usually after a one hour or so hiatus). Make sure that you have systems, a culture and people to ensure that when the build fails, the relevant people are prodded automatically, and it is seen as an urgent priority to fix it. You may also need a system that lets you disable some tests temporarily to prevent builds from being blocked. Your build system must run all the automated tests and communicate the results effectively. Make the build system go the whole hog. If you deploy your system with an installer build that too every time. If the customer can install new versions themselves make sure you place it electronically speaking within their arms reach. Make sure the running software self-identifies its version and that you have a way to correlate that to the exact version of all the sources in the repository. (So you can reproduce it easily for bug fixing). You are aiming for a situation where whenever you want to give the customer a release you have a bang up to date version instantly and very easily ready to go. Culture Change Icebergs Changing the culture of the development people towards Agile is deceptively easy on the surface, but there are unseen risks hence the iceberg metaphor. Developers usually take an instinctive position of supporting Agile, but this is dangerous because some see it as an abandonment of discipline, and simply a route to having more latitude and fun. They are quite often not as versed as you might assume about the real implications of doing it properly and successfully. Education is needed and a readiness to meet and manage some objections. First of all, you might need to raise the bar on design quality, and that might mean some kind of scrutiny of design that you didnt have before e.g. peer design reviews. These take some adjusting to for some developers and can be seen as a threat and a clipping of personal latitude. If you havent got them already, introducing programmatic unit tests for ALL code is very tough to introduce. Few developers enjoy writing them as much as the application code, but its got to be done. They require great self-discipline if they are treated as a separate process, and one good way of solving this is to try test-driven development. (See  HYPERLINK "http://en.wikipedia.org/wiki/Test-driven_development"http://en.wikipedia.org/wiki/Test-driven_development) Test-driven-development sits alongside Agile very comfortably because it can be used as part of iteration definition, and it tends to create constructive influences on design too. Another problem can be acceptance of the customers potentially new power. For Agile to work, the customers contribution to the iteration plans really must be listened to and respected. Developers (and development leadership) have to adjust to being given mandates by the iteration plan, which are short term and will often have very little room for manoeuvre. You cant make Agile work successfully unless the developers accept these power dynamics. If you have an intransigent dissenter, you MUST deal with it. If the person is indispensable, forget Agile (best to see this coming before you try!). Try education and coaching. Escalate to management pressure. Ultimately choose between that person or Agile). Dont fudge or it will end in tears. We Have a Process Who Needs Judgment? When you put a process into place, there is a natural tendency to sit back and rely on it. If you personally were also the champion for it it is quite hard to accept that it may not be working in some respect in your organisation, or your project. But you must. Having a process doesnt mean that you can stop thinking, taking responsibility and using judgment to make decisions. Having a process means that you have done some of the thinking work in advance and the mechanisms you put in place give you a fighting chance to be well organised, and to be prioritising the right things. The process should let you spend more time on creating and delivering software, and less on constantly revisiting how to set about that task. But you cant relax. YOU are still responsible for success, not the process. You have to maintain an active and impartial interest in whether the project is working out, and when it is not think it through and act. You must not let the process block you. Whos in charge here? Having said that, dont throw the baby out with the bath water. Wherever possible, adapt the process deliberately and consciously dont just abandon it. But at the end of the day, we must not forget - it is the project we are serving not the process! Dont take it literally for goodness sake! I am constantly surprised by how often people involved in managing software development when reading about some new idea whether it be Agile or anything else will accept every single detail, absolutely literally, verbatim. My opinion is that this is foolish. I think it arises from the tone of many texts and articles. These often present as gospel, finely detailed recipes for the process or technique they are advocating. First off you are entitled to disagree with experts. One thing I have learned from working in 3 or 4 software development contexts. Is that despite skin-deep similarity there can be huge differences in what is important and what isnt, and in project and technical dynamics. So if you have some skepticism about some aspect of a process being advocated you are probably right for the context in which YOU are the expert. It is inconceivable that the expert will have anything like the understanding you have of your context. So trust your own judgment. Adapt and shape the process to your own project and make it your own. I for example have never quite seen the benefits of pair-programming as the routine way to code. I like to see it at the design stage to improve design quality and spread knowledge. And as a way of transmitting specific experience form one person to another. However a significant proportion of the developers I have worked with, dont like it, and dont benefit from it, and it slows these people down by a factor of maybe five. Thats pretty expensive and de-motivates people so we take a case-by-case judgment. Commercial misfit The dilemma If the organisation you serve is selling a software development service to customers who are not familiar with or enthusiastic about Agile style methods, then you have big obstacles to using it. Your customers will usually have a very strong desire to pass as much of the risk on the project away from their organisation and onto yours. The deal struck with your customer is of course a contract and you can be sure that this will be shaped in the form of some kind of specification and delivery schedule with much financial pain involved if you dont do what you agreed at the contract inception stage. This form of contract is the traditionally accepted way to mitigate the risks of the project from the customers side. This really is a dilemma because Agile is at its heart a fundamentally different approach to mitigating project risk, and advocates of it believe it will produce a better result for the customer in all important respects including risk mitigation. Goodwill We must be honest with ourselves. Agile is predicated on the assumption that both the development and the customer side are committed to the process and recognise the need to engage with it constructively and with goodwill. This is hardly the comfort zone for contract lawyers is it? You can quite understand the contract lawyer worrying about the development party not entering into the spirit of the agreement. What if the developers are really slow? What if the development organisation gets distracted with another project where is our protection? Well my first point is that these concerns are little to do with Agile. You should not be buying software services from suppliers you do not have absolute faith in, and trust. Regardless of the shape of the contracts - dealing with suppliers in this field who you do not trust is commercial idiocy. It is hard enough to make software projects truly successful when everything is in your favour let alone when you add gratuitous extra risks. Chalk and Cheese My second point is - let us not pretend that traditional software development contracts produce genuinely good solutions for customers. Even when traditionally run projects can be shown to have delivered, to budget, schedule and specification which is rare enough for the reasons we have surveyed in previous sections these seldom produce good solutions for customers. Traditional contracts reduce the risk that the development side will renege on the promises they agreed to at the start, but with a model that often delivers perfectly project-managed junk. Agile development on the other hand offers no protection of the same kind but is more likely to produce the best available solution for the customer, in the least time and at the least cost. Which do we want? Tactics? I cant really offer any tactics on this topic. All I can suggest is that buying organisations step back and think about what they are really buying. If you absolutely must have the protection afforded by traditional contracts, then you have to accept the appalling risk factor that the project will not deliver real value. A senior management perspective may be needed because buying people are usually mandated to achieve perceived caution in this way. I contend that a more realistic view is that you are buying a collaboration with a specialist supplier, to work out with you the best development trajectory there is towards your goals and to help you travel along it. This is completely accepted in other commercial domains after all. Consider engaging a solicitor to buy/sell your house. We accept that the costs incurred by the lawyer are pretty much a function of how much time his firm has to devote to the transaction and that he cant be expected to quote a fixed price at the start. The volume of work will be determined by how things pan out, and if a significant problem emerges that neither side could have envisaged at the outset, then its tough luck, but the customer has to pay or withdraw. Note that we trust the solicitor to do a good job and look after our interests professionally. I don't expect the software customers of the world to be too thrilled at this suggestion. I'm not ecstatic about paying my solicitor in this way either. I accept it, because as the customer I recognise that it creates an environment in which the lawyer is able to strive genuinely to serve my best interests. And not retreat behind risk-mitigating price inflation or defensive contract terms. Infancy The dilemma Sometimes it hard to bootstrap Agile and get it going on a new project. All the people may be new to it and havent yet developed the comfortable reflexes about how to do their bit. The process expects us to agree on some development that we can do in a relatively short time that can be described by a user-story or a test, or at least some functionality in the users terms not the developers. Oh, and it has to be production quality from day one too. And we are starting from ground zero code wise. And another thing we havent really got an architecture defined yet even for the first stages. Analysis Refer back to the sections entitled We have a process, who needs judgment and Dont take it literally If your project is at the stage I outlined in the first paragraph it is patently obvious that you cant reasonably expect to go straight for an iteration defined in these terms. Yes you may have a shiny new process but it doesnt spring into life of its own accord the buck still stops with you. So how do we start then? Theres no one-size-fits-all answer, but lets look at some dimensions. If all the people are new to Agile spend some workshop time working through and communicating expectations and getting buy in. Make sure people realise that there will a learning curve with the process and that is ok and expected. Explain to the customer side, that they may need a little patience before you are ready to provide purely customer-experience driven iterations because you need to build some foundations. Explain to the customer that the smart things to think about first, are where the biggest question-marks are about what should be done, or where the biggest risks or unknowns exist. We want to face up to the biggest risks and mitigate them as early as possible. Seek their perception of where these lie too. Lead a brainstorm to see what opportunities there might be to direct development towards routes through the software that are far from complete, but that could provide a coherent and visible application. Maybe provide some temporary dummy inputs, maybe provide some views of data, but no interaction. Maybe provide some GUI screens that look the part but dont do anything yet. Explain that it might be worth investing some early development in some temporary surrogate / dummy objects because that will enable a much faster realisation of a plausible looking application and will provide feedback sooner. Another tactic if there is a customer workflow when using the software, to start with what they do first and ignore what follows initially. Explain you just have to take some time aside to develop your initial architecture and that with the best will in the world this may be of zero interest to the customer. Same applies to infrastructure if you havent got any yet. Its easy to get overwhelmed at this stage. Agree on a sensibly limited set of immediate priorities, stop worrying about everything, and just get on with it. Things will unfold in due course and the whole thing will begin to take shape. Reverse gear How do we get backward steps? Sometimes in Agile we want to take steps that the customer quite reasonably regards as backwards, and these can be tricky to agree to. For example, we have made great progress so far, and the customer has really seen the benefits of the process. At this point we the developers announce that we think a substantial refactoring is required. This is most likely to be for strategic reasons with which the development side has a great deal more sympathy than the customer side. It may be that our reason is to make future development quicker or easier or cheaper. Or it may be that we can avoid a great deal of functionality duplication and reduce future maintenance. Or we may have painted ourselves into a corner and ended up with some badly muddled code that we just know we will regret if it is allowed to live. Our customer is justifiably disappointed he faces the prospect of reduced work on the feature development, and worst still quite possibly having to re-validate and iterate on any changes that show on the outside and affect the user experience. How do we agree on what to do? Well first of all in my opinion, its not just the customer side that has the prerogative to change their mind as we go along. I should note that this may not be the pure Agile stance. The reason we accept the customers prerogative, is because there are common sense reasons for doing so. The same applies equally to development side changes. In both cases, the team that is coming up with iteration plans needs to achieve buy-in from both sides. This may come as a shock, if the development side is accustomed to having unilateral authority over development tactics. The customer needs to share some of the responsibilities faced by development including these longer term development drivers, as we the developers need to accept throwing away some of our code sometimes, because the customer has changed his mind. Pressure and Expediency Can we adopt a Jane Austen cue from that title? ... It is a truth universally acknowledged that a team in possession of a good method, must be in need of a good... . No ok, perhaps not! One of the side effects of Agile, is that we apply more frequent and detailed scrutiny of developers work. This is not an intentional escalation of scrutiny it is a side effect. It feels this way because we have systematic conversations about what we are going to try to achieve at frequent intervals. We work out who is going to do it and at each iteration we inevitably expose how this went to think through the next iteration. Not only that, but this dialogue is very public in front of the development team en-masse and the customer side! This can have a deleterious affect on developers who can feel under much greater pressure and to some extent emasculated in what they can decide for themselves individually. Developers voice This can cause the important influences from the developers internal perspectives to get lost or under-rated. For example the developer may feel that some time out is needed to improve some unit tests, or to finish up some ragged code properly. This is completely legitimate, but in my experience developers cannot or do not always make a sufficiently strong case. They perhaps are not in their comfort zone campaigning for these things, and find it hard to assert that these are fair competition for the users feature and functions ideas. Also, if these suggestions are rejected as priorities in one iteration it takes more confidence again to bring them up again next time. The main remedy here is culture change but it must be led. The development side manager should be sensitive to this problem and listen to the quieter voices, and lend support when necessary to provide level competition of priorities. That doesnt mean always agreeing though! Strain and Heroism Another problem with the pressure that can be felt in Agile, is that the parties often respond to it with a frenzied level of effort and heroism. Initially this is manna from heaven for the management involved, but if we plan to use this method routinely we have to provide a sustainable way of working and sustainable, frenzied heroism is not. When you plan a single iteration the developers will estimate what they can achieve with ambitious estimates and will generally succeed by spending all their time and energy to do so. But if this pattern is repeated every cycle. It means the developers dont get time to breathe their entire, steady state working existence is geared to hitting the iteration target. That simply is not realistic or sustainable. Real world developers must have time for things like: learning new things, providing support, helping each other, attending HR performance reviews, and dare I say it having off days! Again development management needs to intervene and curtail over zealous iteration plans, and help the team find a cadence that is a brisk as possible, but sustainable and realistic. The Agile texts recommend analysing the developers velocity. This is a numeric way to map development estimates in hours into real world elapsed time taking into account the amount of time people really get to do hands on development. The technique also adapts to feedback over time to improve accuracy. I havent tried this yet, but I hope to soon. Part of the reason I havent tried it is because I have never yet found myself in a situation where I have the capacity to use all the management tools and techniques I would like to and I have to choose which ones I think will give the biggest bang for buck as my priorities. I wonder how common this is? Hiatus and Minor Crisis Large refactor dilemma Agile respects code refactoring as something that must be done continuously. The reason for this is that we absolutely must keep our code internal organisation in very good shape and comprehensible if we are serious about being able to embrace frequent change with minimum pain. In the ideal world this is a slightly hidden current absorbed into each iteration. But in my world we occasionally find that a major refactor is really needed. Ok this suggests that we may have got ourselves into something of a pickle and it would have been much better if we hadnt done, but lets face reality. This creates three challenges. Firstly we want to invest time in a substantial amount of development that will result in zero tangible impact for the customer and the customer is unlikely to be hugely supportive of this idea is he? Second, it is difficult to design iterations to drive us through it, that the customer can relate to. Thirdly, unless we are careful, we allow ourselves to temporarily break software that was actually working to the customers satisfaction, and it is dangerously easy to allow ourselves to drift while we are in this broken state. Cave in? First and foremost we need our customers support. We have to face up to the fact that we have got into an unfortunate state. There is a tremendous temptation to acquiesce to pressure from the customer to forget the restructuring and to add the next round of features. This has the attraction that it distracts attention from our rather regrettable status, and is the path of least resistance. In fact there is no black and white answer to this situation. The development side must make a very strong case that carrying on with the design or architecture we have is a very, very serious risk because it will drag us down in the future. On the other hand, we have responsibilities to our broader organisation. If we are a small company non delivery of those features might affect sales / payment / cash flow to a sufficient extent that next months salaries cannot be paid. Do you feel entitled to sacrifice the whole company on the technology altar? Frankly it can be impossible for the two sides to find an agreement in this difficult situation and this is the time to involve more senior management who have the benefit of the broader context needed for this decision making. I found myself in this situation once, and received support from the most unexpected quarter. When I joined a new company, I found the software team was having a terrible time wrestling with an absolute monster of a legacy code base. This code base was beyond redemption and to say that is an absolute last resort it is almost always better to work up from something you have already got than to start from scratch. This really was the exception to the rule. I escalated the problem to our chief executive who was an accountant rather than an engineer. I explained from a broad technical perspective both the risks of the status quo, and also how we could get out of the situation in the longer term but that we couldnt do that as well as service our development roadmap with the old code. He first demonstrated his accountancy credentials by exploring the possibility of buying-in a strategic solution! But when we exhausted that route he simply bit the bullet and asked me to build a team that would allow us to embark on creating a new platform, and to progress a modest development roadmap with the old. It takes someone with the perspective that only senior management have to make decisions like that. Surrogate customer Returning to the Agile case, and the difficulty of engaging the customer with refactoring iterations maybe we should use a surrogate customer temporarily who understands the need to refactor technically? That way we can still use our story based iteration mechanisms and disciplines but our stories are about chunks of refactoring and the post-refactoring resurrection of existing user functionality. I.e. the stories are about user-facing features that already work, but we know we are going to mess about with their underpinnings, so our goal is to restore them to full working order. This approach not only gives us a direct connection to restoring real features rather than complacently thinking we are doing ok, when we provide the infrastructure that should provide the features, but it also prevents us from getting distracted by technological opportunities for the sake of them (i.e. creep), or by long term strategy drivers at the expense of getting back on the customers track. Post mortem Last but not least just how the hell did we get into this state anyhow? Because if we dont learn some lessons from this we are doomed to make the same mistakes again. Here are some possible reasons We are new to Agile, and we are getting too excited and focused on customer features, that we are neglecting the need for adequate design time, and ongoing small-scale refactoring. We are actually not very good at design. There is an authority figure involved who is not listening properly to the development voice. We are a bit scared of refactoring. As for remedies: Being open to learn from mistakes. Coach developers to be assertive about their needs when they compete with the customers. Listen. Dont assume all developers have the experience and training to design well. Supervise design explicitly if you need to, or make design a pair/group activity. Attend to the balance of power in making iteration decisions. Coach people on refactoring if they remain scared it may well be because your design or test infrastructure is not good enough to support rapid change with sufficiently low risk. Snappy Turnaround Difficulty I have difficulty in making iteration turnarounds snappy. Lets say we have a fabulous system for making iteration builds. We will assume that a few hours after the last code check in a nice shiny ready to roll software installer pops out of the system. We will go further in assuming that our customer can simply grab this and install it himself pretty quickly. So far so good. But the following points all conspire to create delays in turning round the iteration. How long in real elapsed time does it take the customer to assimilate, try and judge the new goodies hes been looking forward to? In my experience, we need to allow at least a day for this. Now we have the discussion about what would make good stories to run with for the next iteration. The texts suggest that we leave the iteration meeting with well formed stories, and that the customer will spend maybe a day with us on this activity. My customers cant usually spend a day with us per iteration, and so we need to get some preliminary story ideas and then go away and develop them a bit. The customers cannot be expected to help prioritise stories without some very rough estimates but again for the types of development work I have been involved in over 20 years we very often dont know how to achieve the story solution because this requires some deep and demanding thinking and sometimes experimentation. We discussed earlier about how we must continuously refactor to keep our designs clean as changes come along but the analysis of whether this is required for the stories being talked about is often non trivial and takes time. Response I think the narrative above makes it clear that the iteration meeting cannot necessarily be a black and white and tightly boxed event, but can in fact drift over a few days. But we dont want to sit on our hands and wait for all the answers we must keep going on the partly defined next iteration. We still need the organised iteration meeting to provide a temporal focus for the decision making process, and we should take it as far as we sensibly can during the meeting. But we must also provide a process to finish the iteration shaping dialogue. Our daily team scrum meetings are probably the best forum for this. After all this is the venue for brisk reports on what each person has done yesterday and will do tomorrow. If their activities at the beginning of an iteration includes some new investigation or reporting it is a perfectly natural opportunity to communicate and make decisions which clarify the iteration. In the spirit of all scrums only decisions that can be made quickly should be made during the scrum. Those that take longer should be delegated to be dealt with offline, and the results communicated the next day. Delinquent Customer Digression This title of this section is stated with tongue in cheek, because we as developers know there is no such thing as a delinquent customer. Dont we. This is actually a serious point in its own right that I explore with candidates when I interview software developers. Most developers find it all to easy to fall into the trap of thinking of customers as almost universally hopeless. I think this is because it is actually extremely difficult for developers and customers to meet EACH OTHERS needs and we must invest time, effort, education, coaching and process to make it work decently. Having said that there is a serious point to be made in the particular context of Agile. Agile Customers Agile places very much higher demands on the customer than traditional lifecycles. It is counter productive to deny this, because we absolutely must have proper and realistic buy-in from the customer side for a happy ending. So what do we expect from the customer representative? Oh, only a serious time contribution, intelligence, experience, bravery, and empathy with software development! Really? Hows that then? The time contribution is self evident. We need intelligence and bravery because the role involves important judgment calls and a willingness to accept the consequences of these decisions on a continuous basis. We completely remove the comfort blanket of the formal up front specification with the misleading sense of security this provides. We need empathy with software development because as we develop our iteration plans we will be jointly discussing compromises, priorities and tactics to find the best development trajectory. These conversations will visit programmatic testing, architecture and design, complexity problems, code reuse opportunities, documentation etc. You need some relevant background or a willingness to learn quickly to contribute to this from the customer side. Its quite a tall order when all is considered so we need absolute customer buy in, and willingness to use the right individual. This latter point can be difficult because we need the best person the customer has got to make this work not the joker who wont even be missed if he gets involved. The joker is hardly going to be an effective advocate for the customer team, or to meet the requirements we surveyed above. The person in charge of an Agile project must protest to the ultimate authority if an unsuitable customer side person is dumped on them because that isnt the Agile process it is the doomed process. Excessively Good Customer What? Oxymoron surely? This is not really the correct term what I am referring to is the customer who becomes so well oriented with the development team, that they kind of cross over to the development side, and lose the robust customer advocacy we need them to retain to keep us in good shape. I dont think this is too serious a problem. The individual will normally respond to a spot of coaching in this matter. Alternatively it looks like youve just found a great new development team member in some capacity or other and need to set up a new customer agent in the Agile organisation. Knowing When To Stop Part 1 This section is about knowing when to stop in pleasing circumstances. (See the next section for when to stop in the other sort of circumstances.) Stopping a waterfall Consider the traditional lifecycle. We work furiously to implement the specification. We test our implementation and then lob it over the wall to the customer. We then enter the awful phase of disappointment and acrimony where we try to understand why the customer is so disappointed, and the software we find is actually no good. We go through the pain of trying to change it to put it right but we have a terrible time because this is done overshadowed by the sense of failure and cock up and we are simply not geared up or very competent at dealing with change because it not our natural modus operandi. We enter negotiations to reduce (decimate) the scope in the desperate hope that we can retrieve at least some semblance of usefulness. This is of course a fudge, so when we do eventually deliver something its still not really what the customer needed, so we try to carry on the development as a phase 2, or mask it by trying to absorb it into maintenance or support. Oh, and by the way we are by now spectacularly late, and have butchered quality with our headlong rush. A great many developers I have spoken to have worked on projects that were delivered, but never really adopted in earnest by the customers because ultimately they werent useful enough. Stopping with Agility Agile presents a profoundly different stopping picture. The customer has led us towards usefulness at every step of the way, and helped us make all the compromise / balance decisions along the way. This places us ahead on two counts. Firstly, if we have achieved a trajectory that took us closer to genuine usefulness at every single step, we have completely novel opportunities for stopping. At any point in time we can look at the return on investment for the project or perhaps the value created in usefulness per dollar and take a view about stopping if we have reached what we believe is the optimum, or sweet spot. Thats a pretty amazing benefit once you get your head round it. Its like the way newspaper writers have to write their copy to allow the sub-editors to truncate the piece almost anywhere, and for it still to make sense. The second way it puts us ahead is that we have developed a constructive relationship with our customer in which he has become used to contributing to transparent, common sense decision making around the project, and can see the situation from all sides. He has no fear that we will resist future changes because we have become used to celebrating the opportunities provided by change and we have great coping mechanisms for change. We will have been iterating within the context of the requirements we gathered at the start but of course we do not feel rigidly bound by these (see earlier section). My experience is that a series of iterations will often be targeting a cloud of related requirements. We will have developed stories to achieve these and worked through them in priority or value order. Nearly always the CUSTOMER will find that some of the requirements turn out to be redundant because we reach the point with the important stuff we tackled first, that it is clearly a sufficient response to that area of requirements and it is better value to move on to something else. Ok, so I still havent said anything about when to stop. How about at the deadline? Novel I know. There always is a deadline, but people have become so used to these being missed that we risk becoming de-sensitised to them. (We all know that no-one really expects us to succeed in hitting the deadline largely because with traditional lifecycles we usually fail to). Deadlines have a varied provenance. Occasionally they operate at face-value i.e. that is when the software is really needed. Just as often there are other reasons. Like vital people having other commitments beyond this date. Or we will overrun the budget if we carry on past this date. Or if we didnt offer this deadline the project would never have been agreed to. Etc. It doesnt matter what the underlying reason is, Agile means we can stop at the deadline in the best possible shape that could be achieved by that date. This is because we have at every stage of the way something that is viable in the sense that is of full quality. We have a fully briefed and trained customer, we have a mature and stable deployment mechanism, and above all, we have a feature set that the customer has endorsed as being the optimum possible in the time available. Knowing When to Stop Part 2 This section is about knowing when to stop in horrid circumstances. It is a digression with no connection to Agile. A Fantasy Just imagine that we could summon out of fresh air someone who could fully assimilate the status of the project we are in the middle of. This person would have the wisdom of Solomon, and be an expert in our domain. They would know what each of the people involved was capable of, and all the underlying motives, and competing pressures etc. etc. In other words, this theoretical person is infallible. They would also have absolutely zero vested interest in our project. We invite them to offer their perfectly informed and wise view of the best tactics to take the project forward. It is my opinion that for quite a few projects, their advice would be to stop immediately and accept failure, because to continue would be an unjustifiable investment or I prefer the somewhat grittier expression - chucking good money after bad. This is the gravest end of a continuum used to illustrate a point. As we move back along the gravity scale it may be that other fairly drastic steps would be advised by our expert advisor. For example booting a key person off the project, or recognising a very expensive mistake and facing up to what the remedy should be. Etc. Dont forget this person is infallible, so their advice is unequivocally correct the only rational reaction is to follow it. The Reality Problem Well ok, this is a ridiculous fantasy, but wouldnt it be great? Which rather begs the question of why we dont even try to aspire to the closest real approximation we could get to it? Instead we expect people with massive vested interests to be the people to recognise and deal with this potential situation. The reason we do this is because my outline was a fantasy and the only people with sufficient visibility, knowledge and judgment are the people with massive vested interests. Even if we parachuted someone suitably qualified in to take a look they will be blocked, obfuscated and hindered at every step of the way. We always create a culture around projects that the only outcome we can talk about in polite company is success. Why is this? Loads of projects fail. We have our metaphoric hands over our metaphoric ears. Cant hear you, sorry! The people managing our projects would be jeopordising their careers and reputations if they give serious attention to recognising and dealing with failure. But we still pretend they are going to. Isnt this rank recklessness from a senior management point of view? We are endorsing an organisational device that will allow money to be poured down drains, that we could avoid. Remedies The remedy is obviously a culture that celebrates failure! No wait a minute that isnt quite right is it? This message is not that easy to get across. Lets use an analogy using the culture we create for developers. We constantly reinforce the importance and value of getting development done, meeting deadlines and the whole productivity mantra. But then we confuse everything by saying that going to meetings, taking part in reviews, learning new stuff and all that jazz is also part of the job and important. We want it both ways! This is perfectly reasonable. They may conflict at times, but both are proper duties and responsibilities for a developer. We strive to have reasonable expectations. We acknowledge that these things compete and we make allowances for this affect. We offer an arbitration service as management to people if they need help with making the priority call. We dont think the developer is in any way deficient if they seek our help because it is perfectly reasonable and a discharge of their duties. Well the same thing works for software development management people and their senior management. Their equivalent to the developers productivity mantra is making the project succeed. Their equivalent to all those peripheral responsibilities for developers is also to be accountable for stewardship of the companys money including recognising when the right thing to do is turn the tap off. The senior management must also expect to be consulted on these difficult decisions and need also to provide the arbitration service in the spirit of reasonable and expected occasional help not as the failure of an individual. Disagree? If you reached this far, thank you for your interest. I would be very interested in hearing your constructive criticism and counter-views. See contact details on cover page. Page  PAGE 1 of  NUMPAGE \*Arabic 27 Page  PAGE 26 of  NUMPAGE \*Arabic 27 Peter Howard  HYPERLINK "mailto:peterhoward42@blueyonder.co.uk"peterhoward42@blueyonder.co.uk  HYPERLINK "http://peterhoward42.blogspot.com/"http://peterhoward42.blogspot.com I grant permission to copy and modify this document for any purpose, provided the reference to me as the author is retained.     .wl^lj:UmHnHujUmHnHu&5CJOJQJaJmHnHsH tH u&j>*B*UmHnHphu mHnHu0JqmHnHuj0JqUmHnHu0Jsj} UV 5CJ$\%j59CJU\mHnHtH u 59CJ \ 59CJ\ 59CJ0\ mHnHsH jU$   -.WXPP$xa$ $xx^xa$ $x^xa$!} A_oC  q ; X  r j  l 6P !;<=>?@ABC_`abef̲訖ƈt訖fj.UmHnHu&j>*B*UmHnHphuj4UmHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHu&j>*B*UmHnHphu mHnHu0JqmHnHu&5CJOJQJaJmHnHsH tH uj0JqUmHnHujUmHnHu( #$=>?YZ[\]^_`a}~мЅsesj"UmHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHu&j>*B*UmHnHphuj(UmHnHujUmHnHu&5CJOJQJaJmHnHsH tH uj0JqUmHnHu&j>*B*UmHnHphu mHnHu0JqmHnHu'~ <=>?@սߜսzߜfߜ&j>*B*UmHnHphujUmHnHu&j>*B*UmHnHphu0JqmHnHujUmHnHujUmHnHu mHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHuj0JqUmHnHu&j>*B*UmHnHphu'@AMNOijklmnopq! " # Ӹ䤸zӸf&j >*B*UmHnHphuj UmHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHu&j >*B*UmHnHphuj0JqUmHnHuj UmHnHujUmHnHu mHnHu0JqmHnHu&5CJOJQJaJmHnHsH tH u(# = > ? @ A B C D E a b c d g h  ӹӛӹyӹe&5CJOJQJaJmHnHsH tH u&j{ >*B*UmHnHphuj UmHnHu0JqaJmHnHu&j >*B*UmHnHphu0JqmHnHu#CJOJQJaJmHnHsH tH uj0JqUmHnHujUmHnHuj UmHnHu mHnHu%         3 4 5 6 9 : N O P j k l n o p q r s ԸḤԚzԈԸfԚ&jo>*B*UmHnHphuj UmHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHu&ju >*B*UmHnHphu0JqmHnHu&5CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHuj UmHnHu$    4 5 6 8 9 : ; < = Y Z [ \ ] ^ k l m ԺẦԜœԺzԺf&5CJOJQJaJmHnHsH tH u&jc>*B*UmHnHphujUmHnHu0JqaJmHnHu&ji>*B*UmHnHphu0JqmHnHu#CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHujUmHnHu$  5 6 7 Q R S U V W X Y Z v ԸḤԸԸḂԸtԸjUmHnHu&jW>*B*UmHnHphujUmHnHu&j]>*B*UmHnHphu0JqmHnHu&5CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHujUmHnHu-v w x y z {        ! = > ? @ m&jE>*B*UmHnHphujUmHnHu&jK>*B*UmHnHphujUmHnHujUmHnHu mHnHu&5CJOJQJaJmHnHsH tH uj0JqUmHnHu&jQ>*B*UmHnHphu0JqmHnHu'@ C D O P Q k l m o p q r s t ҷ㷯ݯݍҷ㷯ݯy&j9>*B*UmHnHphujUmHnHu&j?>*B*UmHnHphu0JqmHnHuj0JqUmHnHujUmHnHujUmHnHu mHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHu*89:;>?GHIcdeghijklԺẦԜœԺzԺf&5CJOJQJaJmHnHsH tH u&j->*B*UmHnHphujUmHnHu0JqaJmHnHu&j3>*B*UmHnHphu0JqmHnHu#CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHujUmHnHu$     *+,-12:;<VԸḤԚzԈԸfԚ&j!>*B*UmHnHphujUmHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHu&j'>*B*UmHnHphu0JqmHnHu&5CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHujUmHnHu$VWXZ[\]^_{|}~ ԺẦԜœԺzԺf&5CJOJQJaJmHnHsH tH u&j>*B*UmHnHphujUmHnHu0JqaJmHnHu&j>*B*UmHnHphu0JqmHnHu#CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHujUmHnHu$ ]w<OZYWu0B 6 l   /01267TUVpqrtuvwxyԸḤԚzԈԸfԚ&j >*B*UmHnHphujUmHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHu&j>*B*UmHnHphu0JqmHnHu&5CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHujUmHnHu$5679:;<=>Z[\]abstuԺẦԺԒԺpff0JqaJmHnHu&j >*B*UmHnHphuj UmHnHu&5CJOJQJaJmHnHsH tH u&j >*B*UmHnHphu0JqmHnHu#CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHujUmHnHu$,-.HԺẦԜœԺzԺf&5CJOJQJaJmHnHsH tH u&j">*B*UmHnHphujt"UmHnHu0JqaJmHnHu&j!>*B*UmHnHphu0JqmHnHu#CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHujz!UmHnHu$HIJLMNOPQmnoptuԸḤԚzԈԸfԚ&j$>*B*UmHnHphujh$UmHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHu&j#>*B*UmHnHphu0JqmHnHu&5CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHujn#UmHnHu$ $%789STUWXYZ[\xyz{ԺẦԜœԺzԜœljV'UmHnHu&j&>*B*UmHnHphuj\&UmHnHu0JqaJmHnHu&j%>*B*UmHnHphu0JqmHnHu#CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHujb%UmHnHu*$%&'+,678RSTVWXYZ[wx夲tftjJ)UmHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHu&j(>*B*UmHnHphujP(UmHnHujUmHnHu&5CJOJQJaJmHnHsH tH u&j'>*B*UmHnHphu mHnHu0JqmHnHuj0JqUmHnHu(xyz~"#սߜߜtftߜj>+UmHnHu&5CJOJQJaJmHnHsH tH u&j*>*B*UmHnHphu0JqmHnHujD*UmHnHujUmHnHu mHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHuj0JqUmHnHu&j)>*B*UmHnHphu$#$%)*456PQRTUVWXYuvwx|}սߜսzߜf&j->*B*UmHnHphuj2-UmHnHu&j,>*B*UmHnHphu0JqmHnHuj8,UmHnHujUmHnHu mHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHuj0JqUmHnHu&j+>*B*UmHnHphu(   /01245RSTnoprstuvwɷɯﯛɯyɇɯe&j/>*B*UmHnHphuj&/UmHnHu&5CJOJQJaJmHnHsH tH u&j.>*B*UmHnHphu0JqmHnHu#CJOJQJaJmHnHsH tH uj0JqUmHnHuj,.UmHnHujUmHnHu mHnHu0JqaJmHnHu' )*+-./012NOPQSTqrsӹӛӹyӹe&5CJOJQJaJmHnHsH tH u&j1>*B*UmHnHphuj1UmHnHu0JqaJmHnHu&j0>*B*UmHnHphu0JqmHnHu#CJOJQJaJmHnHsH tH uj0JqUmHnHujUmHnHuj 0UmHnHu mHnHu%   !;ԸḤԚzԈԸfԚ&j3>*B*UmHnHphuj3UmHnHu#CJOJQJaJmHnHsH tH u0JqaJmHnHu&j2>*B*UmHnHphu0JqmHnHu&5CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHuj2UmHnHu$;<=?@ABCD`abcghpqrԺẦԜœԺzԺf&5CJOJQJaJmHnHsH tH u&j5>*B*UmHnHphuj5UmHnHu0JqaJmHnHu&j4>*B*UmHnHphu0JqmHnHu#CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHuj4UmHnHu$~!$$&&12B6M6=<E<<<@@AAAQARApAqAAAA|tjZ7U0Jqjy6U6]mH sH 0Jr5\aJmHnHsH/0Jr5B*CJ KH\^JaJmHnHphffsHmH sH  jU&5CJOJQJaJmHnHsH tH uj0JqUmHnHu mHnHujUmHnHuj5UmHnHu-tW=L#$$%&&S'5((),-U..f/0 @  h!  !! 012 2B3E455=7\999S<<==>>?@SATApAAAA-BB @ AAAAA B BB+B,BL)LPP67]u  '(./0156HIKLTU[\^_cdvwyz}   4 5 7 8    mH nH sH tH jF:UCJaJ mH sH j9U5CJ aJ mH sH  mHnHu6]j8UmH sH j8U jU0JqDBLCHcIpI|JJLDPIRUUUVVY[^^_.ade.i&jHjzkm @ mmopkr{rWssuwx!yy'|C}~MAb]9   @9Wڍ "͔DHZf)=9B^l'8@ @ @Ic\e_H;'&UMlu  @uOa "55Md{eZmR^(  @d b;(PTiyZAs4 @ 6FA w Z x   >7  @UJ0is!MN{|}6 7 8 $a$ @8      $*$a$ 1h/ =!"#$%' 01h/ =!"#$%' 01h/ =!"#$%# 01h/ =!"#$% 1h/ =!"#$%F'(dCtYJFIFC    "$$"!!&+7.&(4)!!0A049:=>=%.CHCU`?V ѕ3a+ ˤV0(T+ eǠ< Vo6X`q enU|hxGBE$R.8@n?\"<Ҡ0MЈ@ @e VB1P@_"<"0 A00 A@@'BH`LR0`7+_BN4X74@H*,Z@/G<XTe)B% 0V5Q/ `i5LD<#,dR(AX*3@fACKtBI} "V+ 13V0ђR xt!FXEJDZ(gtxOQA aX A@vExeLPT̩@)XPa} h(tU U30 I ZEtvT"3t&ݐPCu%$@UE'BG?W(2XP~| ŽGr2UCt( P )@EIJVeI0#%LɀBOHteQPH ɐ7X7h3ŁeEQCǁ P%M~H 0&(P A"'H 7l(¡Q&siHPF F"L ]_HOa[7a( C(֐ v耥L -J2(x(Yg2Z(/00pf@P.I;d1(h-HTb4-, BvF@$8nX oPH *2Tt&x+*)\xeI 1t"."@@/  T(D5R+ '4 "Ȋ0E0ȕ '`(R*9戤J4,dUQI"+.ʝSP\PDhVP:}*5˸% 'lʺ5!! ALE LR" aP=#jZ(D* j*BE0ZHPI„z45XDgDTphCXh (jT)Qb)5j%@VH @t#"Q(8To`FlN[hWR@ -RY0(Cǥ\l S QB`+Rx *tjhEpXj\ZN3Q 訁|vB*k@nCۢUh@^?d `VST@ 0ViAQYh+πL+<E &$XT<^Ae`q~Z h B=d XE"vJ7h7 @QB9Q-h(+0 F@`TU)񈊼@Z(X:eAd%A2 "OV ZZ ^?B2 .qf*&E*PA@x 2_?}E `Bn-ղtB"+-@#T(L(1ZrhJ*ѸsDV@52N07h <``2d@PR֐4]CKn0 TPaYS8P@/^X*ECcRtAiO2(tB848aC_ 4H,G3 ~M: 5L  $@P բ-R[9bUѠx&E40k z%V"ORGG*YPvEG5JJSCo4H2S/G\(bsiDAm$ޅ[`?,l N+%*eOTtPAގ.T,)tR(/o5 6TJxȥH 4@J$@5@d Ei uQDR0_mE_b$Xf@\((1_}"DRO@HeCz:<E 3M\JR P8Ef: ɶ@a %/ N4B E[ ,(g@*fZChe(2 bd P2AHТ_k@57xTO_ V$+HU݀Q(@ lT ,`7 d `dHdPEALTfd"fR8PKQ*(Y0DDkH%HtZ99<'EG<(ְ+G- H 1-/EDdH`ik$ ', K h\( @ 4Q2 2aF`R.2i %洐 Pc(Ӱ t9[TX,Q?GDVit -(RZ\,FX+HhXeA 00 ̣ 0 d䊳*Q@`R3@XPuPd2 tMo8QaEPSy 贊_`e2T/* c7E+`R@A@+*E p Q(ƈ q:|G 4@XPr U 'Q(_@_*[aQ%~|5&JbT"ItTl}P(+poHb*3wŽoDeH €++*<>2Œ@Y0t %D"Rrv PG1F@` 3VQ#"RToDiLboiH%@}',dS'1F]&*uL)Hc4  lG:xeE"H(tA6ER* p ` ϤR4@X0H-7PVX<`DT Cc Lhb^HZH%V'@N1 h #d  FUH(b$d  1UOzoVX2+Q,@@T^Fx`/:"tP mQhZ*#,dQ@*N0(S[*ׂk(TJ,@ p@fIQ3{+`<J^PP b"(@Mƈ0:E K DRp.衐 ݔVOB 1T|bӀsrDSЃ- YQ@{l ((HqDT5 +)P iPj „dg , Y% +XTd'Fkn`<P@5@&M*ohT%?BMS""bEf A"…l]ZdT*Sd;KH("*_(CZ_4p TdU>TU+ҡҤ(OW`޲(T;0o8ҲN{ T0U @E`0a@`@+t@c^# GJdoHE3D ,*3 +YFR@cI `3;X™p!54bQXƊ$=(hƀ_GKV@PX f%d(E Tl@l R(2PTEZ"` XhjSɀcx(g%"  =E P )PP+ 7HIC* t @:EN@D_H H2DQ(QRvȠ\ t lip 2(oMeht |(IaSA?‰ tjV*) < AX@lυˀMhPR6@b#j tDdC.EKH`S!`W%   ,`?DdEeZ  6A?2|ڹa# Dq`!|ڹa# + ixcdd``.c```baV fx2+`$@!$1#?7A;CXk4c]FIp3f112B@"+g^qQir^VA"*~v{&121)W20b`bPc h{ 320&}DyK _Toc203227608}DyK _Toc203227608}DyK _Toc203227609}DyK _Toc203227609}DyK _Toc203227610}DyK _Toc203227610}DyK _Toc203227611}DyK _Toc203227611}DyK _Toc203227612}DyK _Toc203227612}DyK _Toc203227613}DyK _Toc203227613}DyK _Toc203227614}DyK _Toc203227614}DyK _Toc203227615}DyK _Toc203227615}DyK _Toc203227616}DyK _Toc203227616}DyK _Toc203227617}DyK _Toc203227617}DyK _Toc203227618}DyK _Toc203227618}DyK _Toc203227619}DyK _Toc203227619}DyK _Toc203227620}DyK _Toc203227620}DyK _Toc203227621}DyK _Toc203227621}DyK _Toc203227622}D  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry  Fp٪?@Data :WordDocument lObjectPool?p٪?_81821108 F??Ole CompObjPObjInfo  FPackagePackagePackage9qOh+'0  4 @ L Xdlt|ss Peter HowardoOCXNAME contents Ole10Native1Table iInsruct2.jpgC:\pch\tss\MARKET~1\pics\insruct2.JPG&C:\pch\tss\MARKET~1\pics\insruct2.JPGdJFIF``C    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?nEJz))yTז(-yHE,9ªJǥyOOI<9lYdXgP}3H.}o aj&[`kcE.cj0ܲue\u<-XK[!Ll[cS̍=}dHڳŔKm'B>e!5UwHSzawu UIu02^CwgҨ$!=ꤨ3[ܼsH'Pw#Ҧ6+*m}u㩎& qT0*Ouir${:s.=khc dU]# Е|A4L -!l81X3 qUΉT 46zv2 ,HR)`*wJ@Iy8lRx '6 Dd4*Ϛҳ0C==- _D$MQSZ.[}̘ bƩ\Kֵ9e+jI"pZp7r0kyZe+zut&+0=h+AF= &x!A+*0r2=+4i1,Gq5Qs9GNiUȈU ;~dzZsHJwjwjm1 #/qOcZҳ V9& Z|J+p3jߊCp1wcqN.X4[M[Ng'[2rl/p(Ҋf~Hkw:e;pm | im|a(;Iw9 DƹgKG>晑Nz:1pr W^~,R9.nnW<3_8)V 2ln*eV<>͙0_U?w9>~y#>%C[;xwCy(;5flWHe2yh5n )GZZM\ ,B!CA}w~v`i1iFhp=N+Oώ hW9Asgq] Gp:?cS(˹Wn~AJz5& 0xhTk{Zwʜ`ڶ_ !`Oj~8,B2zU+bYن 7VmmZ^T"kԤdy5fRGa7c =W9} ;+J¥guv0l-AwQ!SM$p6~W;OvF zWiW:>f]jXn$OަAF\C1Ҋº ?\$FyM҅ƪxkM6zHWg55\(Ҳ)\Uxy*DZ `3xִd4G_p.4@yR`ת:~*[]]@I?Jrќ87"KXEm w {?)jz^[zh†6Gq F54:u@ g'ω/9zW4xzJ3Z9/AV&8{]i@F:s@Ɗ[>{75<;1鐥䑗iۖ[*Ѵ,gT1r9+qҽNlJ(0Bɉ*d/O$\P]$88޷l {2n]g eFG"k-o=+m@qHBroUj8ڥX2WX cy?ƻ6h~C۱@#[\Y>*>+_LWm #Ri|0^xמθ[kNT+tZ+3>t=#'k{H~X?u7Q>el>9Yӫ=Ўq +x%Ziwϗ{M +dw H80y5QI y,֩֟(u!<"+n"#ՌȲS^>V>JQMR# +uͽ2D W{8!I 5,x+jrRfrͪy;)WsRy#U imp0%,1̿\su ),ڣ"#ͯhWĒj;v#5^YO*Hb$ۇm"LQLy wu6m d_j] Kpi̪Mhi}/Q^Ĩ|[s]׍cO r 5EiXS3V$Fܤ0NY@/L?ѥ'9FsVawFYcT`Ѹ}8޵%5vXaqGR^KzԥŽҮ~Wbq˱?z.Gz:2L$Wfwn&9:Q@yvٮ;ۨ$g2s"]=.0:O ǭ^O493$JՄ#;!-w,:W}o+)Gᑚ,&wd"ka"u9Y)G.&+ĺz56b2qWL<,zWӐB"6 1Lq#]:F9kW=+#<5p*řQY0~ v0GuYWq:x5# l54]N<#G^a f8h\%ќ~mug+< gƞS)}Mzޗ3WwL7ҵ/kQ4bMGQXRJ;׹Y&fbq4SndOһ>044Hx|<ϟ~'ߥ׊͒ &իnK4^$&u&O+kSVS)"$ ENiC:N=]5{KPڈ#cבt}ՠa68R1gō|~'kR=d`Yio$db^4F4$ e>׎HvjTeE*s~ZKx%khK6ñAC=3\qq^>O?+𫉝_1JOǪm: 4y<ѹOkž#\[vZLX?tAM|⏃tѭi+uh4a֯xNXkY C dĎLĚ5͵.iPN9|k^9II'J G@9G,1ɀW&\S|9koHd{2Ms|[m4PRARЅ呤Zǵi cc񯛬]գʺ̅O}+š=sZg&'teJ \z=c^(j&Nioԛ];Kj [}Tγ 3})Hׂj cf*amц٢VP=L𭎥o}Ա0p9ּ;WGk^+kW_f "஡c.ӨDצ[RpHQH'Zu=XIkriVO۳1UD'|}.1עʽ~䚍ll5~׮J9cgM]njCҚ:đbʊ*X%56*J+/qD(ta3%袹U^3n?ͨ&5~{Q]'(SwED>G$7IB}cY$ph=|%HZi!r!bT~\C+A(#j,*1PW8!&D'GES%}VH~/|޾QYѿ?_b{׭|sc&οZQEuۭ,(     !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHyK _Toc203227622}DyK _Toc203227623}DyK _Toc203227623}DyK _Toc203227624}DyK _Toc203227624}DyK _Toc203227625}DyK _Toc203227625}DyK _Toc203227626}DyK _Toc203227626}DyK _Toc203227627}DyK _Toc203227627}DyK _Toc203227628}DyK _Toc203227628}DyK _Toc203227629}DyK _Toc203227629}DyK _Toc203227630}DyK _Toc203227630}DyK _Toc203227631}DyK _Toc203227631}DyK _Toc203227632}DyK _Toc203227632}DyK _Toc203227633}DyK _Toc203227633}DyK _Toc203227634}DyK _Toc203227634}DyK _Toc203227635}DyK _Toc203227635}DyK _Toc203227636}DyK _Toc203227636}DyK _Toc203227637}DyK _Toc203227637}DyK _Toc203227638}DyK _Toc203227638}DyK _Toc203227639}DyK _Toc203227639}DyK _Toc203227640}DyK _Toc203227640}DyK _Toc203227641}DyK _Toc203227641}DyK _Toc203227642}DyK _Toc203227642}DyK _Toc203227643}DyK _Toc203227643}DyK _Toc203227644}DyK _Toc203227644}DyK _Toc203227645}DyK _Toc203227645}DyK _Toc203227646}DyK _Toc203227646}DyK _Toc203227647}DyK _Toc203227647}DyK _Toc203227648}DyK _Toc203227648}DyK _Toc203227649}DyK _Toc203227649}DyK _Toc203227650}DyK _Toc203227650}DyK _Toc203227651}DyK _Toc203227651}DyK _Toc203227652}DyK _Toc203227652}DyK _Toc203227653}DyK _Toc203227653}DyK _Toc203227654}DyK _Toc203227654}DyK _Toc203227655}DyK _Toc203227655}DyK _Toc203227656}DyK _Toc203227656}DyK _Toc203227657}DyK _Toc203227657}DyK _Toc203227658}DyK _Toc203227658}DyK _Toc203227659}DyK _Toc203227659}DyK _Toc203227660}DyK _Toc203227660}DyK _Toc203227661}DyK _Toc203227661DyK yK phttp://en.wikipedia.org/wiki/Agile_software_developmentDyK yK 6http://agilemanifesto.org/DyK yK <http://www.agilealliance.org/DyK yK jhttp://en.wikipedia.org/wiki/Test-driven_developmentDyK yK Lmailto:peterhoward42@blueyonder.co.ukDyK yK Fhttp://peterhoward42.blogspot.com/SummaryInformation( DocumentSummaryInformation8tCompObj jeteete Normal.dotdPeter.d52eMicrosoft Word 9.0@A@l@e@F>(u  FMicrosoft Word Document MSWordDocWord.Document.89q  ow  TitleH  id@d Normal$a$1$*$xA$+B*OJQJCJmH sH PJ^JaJ_HtHz@z Heading 16@& & F & F^]`h<$B*phffCJ 5KH^JaJ \l@l Heading 26@& & F & F^]`<$CJ5^JaJ\ll Heading 36@& & F & F^]`<$CJ5^JaJ\pp Heading 46@& & F & F^]`<$OJQJCJ5aJ\ll Heading 53@& & F & F^]`<CJ65aJ]\nn Heading 63@& & F & F^]`<OJQJCJ5aJ\hh Heading 73@& & F & F^]`<OJQJCJaJnn Heading 83@& & F & F^]`<OJQJCJ6aJ]d d Heading 93 @& & F & F^]`< CJ^JaJ<A@< Default Paragraph Font8O8 WW8Num1z3OJQJCJ65aJ<A@< Default Paragraph Font*O* WW8Num5z0OJQJ*O!* WW8Num6z0OJQJ*O1* WW8Num7z0OJQJ*OA* WW8Num8z0OJQJ,OQ, WW8Num10z0OJQJ6Oa6 WW8Num11z0B*phOJQJ0Oq0 WW8Num11z1 OJQJ^J,O, WW8Num11z2OJQJ,O, WW8Num11z3OJQJ6O6 WW8Num12z0B*phOJQJ0O0 WW8Num12z1 OJQJ^J,O, WW8Num12z2OJQJ,O, WW8Num12z3OJQJ,O, WW8Num13z0OJQJ0O0 WW8Num13z1 OJQJ^J,O, WW8Num13z3OJQJ0O0 WW8Num15z0 OJQJCJ0O!0 WW8Num15z1 OJQJCJ0O10 WW8Num15z2 OJQJCJ6OA6 WW8Num16z0B*phOJQJ0OQ0 WW8Num16z1 OJQJ^J,Oa, WW8Num16z2OJQJ,Oq, WW8Num16z3OJQJ6O6 WW8Num17z0B*phOJQJ0O0 WW8Num17z1 OJQJ^J,O, WW8Num17z2OJQJ,O, WW8Num17z3OJQJ,O, WW8Num18z0OJQJ0O0 WW8Num18z1 OJQJ^J,O, WW8Num18z3OJQJ6O6 WW8Num19z0B*phOJQJ0O0 WW8Num19z1 OJQJ^J,O, WW8Num19z2OJQJ,O!, WW8Num19z3OJQJ6O16 WW8Num21z0B*phOJQJ0OA0 WW8Num21z1 OJQJ^J,OQ, WW8Num21z2OJQJ,Oa, WW8Num21z3OJQJ6Oq6 WW8Num22z0B*phOJQJ0O0 WW8Num22z1 OJQJ^J,O, WW8Num22z2OJQJ,O, WW8Num22z3OJQJ,O, WW8Num24z0OJQJ0O0 WW8Num24z1 OJQJ^J,O, WW8Num24z3OJQJ0O0 WW8Num25z0 OJQJCJ0O0 WW8Num25z1 OJQJCJ0O0 WW8Num25z2 OJQJCJ,O, WW8Num26z0OJQJ,O!, WW8Num26z1OJQJ,O1, WW8Num26z3OJQJ.OA. WW8Num27z0 B*ph0OQ0 WW8Num27z1 OJQJ^J,Oa, WW8Num27z2OJQJ,Oq, WW8Num27z3OJQJ,O, WW8Num28z0OJQJ0O0 WW8Num28z1 OJQJ^J,O, WW8Nu՜.+,D՜.+,, hp|  ow  TitleH 8@ _PID_HLINKSAh@S5http://en.wikipedia.org/wiki/Test-driven_development@Phttp://www.agilealliance.org/s,Mhttp://agilemanifesto.org/QJ8http://en.wikipedia.org/wiki/Agile_software_development5C_Toc2032276615=_Toc20322766057_Toc20322765951_Toc2032276585+_Toc2032276575%_Toc2032276565_Toc2032276555_Toc2032276545_Toc2032276535 _Toc2032276525_Toc2032276515_Toc2032276505_Toc2032276495_Toc2032276485_Toc2032276475_Toc2032276465_Toc2032276455_Toc2032276445_Toc2032276435_Toc2032276425_Toc2032276415_Toc2032276405_Toc2032276395_Toc2032276385_Toc2032276375_Toc2032276365_Toc2032276355_Toc2032276345_Toc2032276335_Toc2032276325_Toc2032276315_Toc2032276305_Toc2032276295}_Toc2032276285w_Toc2032276275q_Toc2032276265k_Toc2032276255e_Toc2032276245__Toc2032276235Y_Toc2032276225S_Toc2032276215M_Toc2032276205G_Toc2032276195A_Toc2032276185;_Toc20322761755_Toc2032276165/_Toc2032276155)_Toc2032276145#_Toc2032276135_Toc2032276125_Toc2032276115_Toc2032276105 _Toc2032276095_Toc203227608z#http://peterhoward42.blogspot.com/n&mailto:peterhoward42@blueyonder.co.ukm28z2OJQJ,O, WW8Num29z0OJQJ,O, WW8Num29z1OJQJ,O, WW8Num29z3OJQJ,O, WW8Num30z0OJQJ0O0 WW8Num30z1 OJQJ^J,O, WW8Num30z3OJQJ6O6 WW8Num31z0B*phOJQJ0O!0 WW8Num31z1 OJQJ^J,O1, WW8Num31z2OJQJ,OA, WW8Num31z3OJQJ6OQ6 WW8Num32z0B*phOJQJ0Oa0 WW8Num32z1 OJQJ^J,Oq, WW8Num32z2OJQJ,O, WW8Num32z3OJQJ6O6 WW8Num33z0B*phOJQJ0O0 WW8Num33z1 OJQJ^J,O, WW8Num33z2OJQJ,O, WW8Num33z3OJQJ6O6 WW8Num34z0B*phOJQJ0O0 WW8Num34z1 OJQJ^J,O, WW8Num34z2OJQJ,O, WW8Num34z3OJQJ6O6 WW8Num35z0B*phOJQJ0O!0 WW8Num35z1 OJQJ^J,O1, WW8Num35z2OJQJ,OA, WW8Num35z3OJQJ6OQ6 WW8Num36z0B*phOJQJ0Oa0 WW8Num36z1 OJQJ^J,Oq, WW8Num36z2OJQJ,O, WW8Num36z3OJQJ,O, WW8Num38z0OJQJ0O0 WW8Num38z1 OJQJ^J,O, WW8Num38z3OJQJ:O: WW8Num39z3OJQJCJ65aJ,O, WW8Num40z0OJQJ0O0 WW8Num40z1 OJQJ^J,O, WW8Num40z3OJQJBOB WW-Default Paragraph Font.U@. Hyperlink B*ph>*8O!8 Normal + BoldOJQJ5\pO"1p )Style Normal + Bold + 18 pt Not Bold Blue B*phffCJ$>'@A> Comment Reference CJ6aJ>V@Q> FollowedHyperlink B* ph>*VOaV Style Left: 1.75" CharOJQJmH sH _HtHHOqH List Bullet CharOJQJmH sH _HtHDOD Body Text CharOJQJmH sH _HtHFOF Body Text First Indent CharFF Heading zx$OJQJCJPJ^JaJ.B. Body Text {xx / List|^J@"@ Caption }xx $CJ6^JaJ]&& Index~ $^J,, Header  !, @, Footer !>@> TOC 1 h! CJmHsH5aJR@R TOC 2- ! h^h]`<<mHsH828 Normal + Blue B*phXBX Bullet + Blue"^]`x B*phlRl Style Blue Before: 6 pt* @  ^ ]`P,b, Comment Text8ab8 Comment Subject5\@@ Balloon TextOJQJCJ^JaJ>>@> Title$a$CJ5PJ^J\8J8 Subtitle$a$CJ6aJ]XX Style Left: 1.75""   ^ ]`<Z< Plain Text  OJQJ^JJ0J List Bullet" h^]`F:F List Number 2^]`XMX Body Text First Indent ^ ]`TC T Body Text Indent"h^h]`xx\N  \ Body Text First Indent 2 ^ ]`.6Q" . List Bullet 2JY2 J Document Map-D(M OJQJ^J0B 0 Frame contents>R > TOC 3" % 6^6]`>b > TOC 4" % Q^Q]`>r > TOC 5" % l^l]`> > TOC 6" % ^]`> > TOC 7" % ^]`> > TOC 8" % ^]`> > TOC 9" % ^]`J J Contents 10" %  ^ ]`0P@ 0 Body Text 26]::;|"|K|t|| -.WXA_oCq;X r  j ]  w < OZYWu0BtW=L  !""S#5$$%()U**f+,-. .B/E011=3\555S8899::;<S=T=p====->>L?DcEpE|FFHDLINQQQRRUWZZ[.]`a.e&fHfzgiiklkn{nWooqst!uu'xCyz{M|A~~b]9Wډ "͐DHZf)=9B^l'8@Ic\e_H;'&UMluOa "55Md{eZmR^(d b;(PTiyZAs46FAwZ x    > 7 UJ0is!MN{|}678000000000000000000000000@0000000000000000000000000000000000000000000000000000000@0`0`0 000000000 00 0  00"0"0"0"0"0"0"0"0"0"0" 0 0--0.0.0.0.0.0.0. 0--050505 0--090909090909090909090909090909 00bE 0bEbE0{F0{F0{F0{F 0bEbE0Q0Q0Q0Q0Q0Q 0bEbE0Z0Z0Z0Z0Z0Z 00%f0%f 0%f%f0i0i0i 0%f%f0jn0jn0jn0jn0jn 0%f%f0t0t0t0t 00z0z0z0z0z0z 00000000 00ى0ى0ى0ى0ى 00000 0 0GG0Y0Y0Y0Y 0GG080808 0GG0&0& 0GG0?0?0? 0  00 00[ 00000000 0  0000 00L 0 0000 00N0N 00!0!0!0! 0  0440L0L0L0L 0440000 0440Y 0440Q0Q0Q0Q0Q0Q 0  0000000 0000 0 000 00h0h0h0h0h0h0h0h 000 00 0000 0000000000 00Y  0Y Y 0 0 0 0 0  0Y Y 000000 0Y Y 000 00h0@0@0@0@0 000000000------------------------[[[^~@#  v @ V Hx#;A  0Bm9@u8    <>?Aa>Z\]_>Njlmo">@ACc5Oknoq589;[l 6RUVXx    ? P l o p r     : H d g h j  , ; W Z [ ] }    1 U q t u w  6 9 : < \ t -ILMOo8TWXZz&7SVWYy$5QTUWw 1Sorsu*-.0Pr <?@Bbq<=Q=p==== >+>6: X%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TXXXX '*3:=BUX^!!Bad=XXl,R$(dCtY'|q@(  l  <A  H N  3  < C   o3t< t t6 _Toc203227608 _Toc203227609 _Toc203227610 _Toc203227611 _Toc203227612 _Toc203227613 _Toc203227614 _Toc203227615 _Toc203227616 _Toc203227617 _Toc203227618 _Toc203227619 _Toc203227620 _Toc203227621 _Toc203227622 _Toc203227623 _Toc203227624 _Toc203227625 _Toc203227626 _Toc203227627 _Toc203227628 _Toc203227629 _Toc203227630 _Toc203227631 _Toc203227632 _Toc203227633 _Toc203227634 _Toc203227635 _Toc203227636 _Toc203227637 _Toc203227638 _Toc203227639 _Toc203227640 _Toc203227641 _Toc203227642 _Toc203227643 _Toc203227644 _Toc203227645 _Toc203227646 _Toc203227647 _Toc203227648 _Toc203227649 _Toc203227650 _Toc203227651 _Toc203227652 _Toc203227653 _Toc203227654 _Toc203227655 _Toc203227656 _Toc203227657 _Toc203227658 _Toc203227659 _Toc203227660 _Toc203227661 "-.59cE|FQZ&fikntzډHZ9'@\MO"5MZRiZ  i  !"#$%&'()*+,-./012345 "..59oEFQZGfizn u{!YeA7Hd%k`4Lcl]'x5w  qXX  c!i!q!w!y!!""-.<R=T=\=]=a=p=======,>->1>2>5>89PQU !'15LT_cz|}58XX ?>]Nm"AOo9l6V P p  H h ; [  U u  : t -M8X7W5USs.r @q<R=p===,>LyLy78}7LUȈɈqqrsӭ׭ʰʰ&qr!'15LT_cz}}5778XX ?>]Nm"AOo9l6V P p  H h ; [  U u  : t -M8X7W5USs.r @q<R=p===,>7ssӭ׭ʰʰ&qr}}5778PeterC:\pch\pws\agile.doc...OJQJCJ65aJ...  ....  .....  ...... ....... ........Outline@(D@@UnknownGz Times New Roman5Symbol3& z Arial;Wingdings?5 z Courier NewO& k9?Lucida Sans Unicode5& zaTahomaU&Arial Unicode MSArialBh=&EFD=&4(uweC(A0dX2 Peter HowardPeter