Agile for Managers - a brief overview of agile methodologies

//Disclaimer: this document contains nothing but my personal opinions, based on about 18 months experience using and teaching agile methodologies. I tried not to say anything that I wasn't fairly sure about, but it's possible that I didn't say something clearly and that my meaning will be misinterpreted. If I learn of such issues, I will update this document.//\n\nThis document represents a well-organized brain dump of my opinions about the various agile methodologies, as of Spring 2006. It's essentially a "knowledge learned" from my experience at [[ThoughtWorks|http://www.thoughtworks.com/]], where I was a Business Analyst / Project Manager. It's most useful in direct conversation with me, as I use it as a reference for deeper conversations. But my hope is that it's also useful in it's plain written form. Please let me know :)\n\nI'm going to start with broad overviews and work down into the detail from there. None of this will discuss all the pecularities that come with actual practice; that's why this is "Agile for Managers" :) \n\nI'd suggest reading in this order:\n* WhatIsAgile? \n* StrengthsAndWeaknesses\n* HistoricalIssues\n* ProcessOverview\n* TeamRoles\n* CommonPractices\n* DeeperInsights\n* AgileResources\n\n

It's difficult to quickly describe what the AgileMindset really is. I'll make an attempt, however, and say that it's some combination of:\n* The ideas in the ManifestoForAgileSoftwareDevelopment (and the PrinciplesBehindTheAgileManifesto)\n* A firm belief that change is good ("embrace change")\n* A willingness to put something imperfect on the table, and then refine it later (vaguely like the 80/20 rule, or a "less is more" approach)\n* A strong awareness that the people matter most, and that Teams are Good^^TM^^\n\n

The ManifestoForAgileSoftwareDevelopment and PrinciplesBehindTheAgileManifesto, of course.\n\nEach of the methodologies have standard places to find information, easily found through google. The pages below list a few of them:\n* ExtremeProgramming\n* [[Scrum]]\n* CrystalClear\n* [[DSDM]]\n* FeatureDrivenDevelopment\n* [[RUP]]\n\nThe [[C2 wiki|http://c2.com/cgi/wiki?WelcomeVisitors]] (also called "The Portland Pattern Respository") is the best resource in the world for learning about the real issues in agile methodologies, even though it's not specifically focused on agile.\n\n

I'll often say "agile teams" and not "agile methodologies" - preformance improvements happen when the team improves, not when the methodology improves. The methodology is just there to enable to team to perform better. And the best performance comes from teams that have the AgileMindset, not from teams that are rigidly following a specific agile methodology. The practices described here are the ones that most agile teams use, but there are certainly agile teams that will break the rules without losing their agility.\n

!!UserStories\nMost agile methodologies have some form of User Stories (or "Features" or "Backlog Items"). These are brief descriptions of user-based functionality, that are implemented by the developers. This is a deep, deep topic; please see UserStories.\n\n!!Business collaboration / prioritization\nAll agile methodologies insist on having close collaboration with a business user (often called "Customer"). Some prescribe that the Customer should sit with the team. What usually happens is that domain experts and analysts become "Customer Proxies" for day-to-day questions, and the actual Customer is only consulted occasionally. Most importantly, though, the Customer is entirely in charge of the prioritization of the Stories, and is asked to review/change that prioritization every iteration. This means that the developers are always working on the highest-priority work, and that business value is realized with each iteration, not in one "big bang" at the end of a long project. \n\nThis close collaboration also helps the team avoid work. In a traditional (requirements-based) process, developers make assumptions about which features are important, or what a requirement means, or about how something should work. These assumptions are sometimes wrong, and days, weeks, or months can be wasted on work that the business didn't really need. The close collaboration helps stop that before it happens.\n\nClose collaboration also shortens the feedback loop. In a waterfall-type process, the business user rarely (if ever) gets to see actual working functionality, and usually not until the very and of the process. In agile processes, they see working functionality every iteration (1-4 weeks), and can refine their ideas and priorities accordingly. The net result is that they often move in unexpected directions and/or de-prioritize work that would have proven less valuable than something they discovered because of this frequent feedback.\n\n!!Acceptance testing\nIn practice, there is usually some form of Acceptance Testing - simple, business-scenario-focused tests that prove that the developer built what the Customer/Analyst actually asked for. Ideally these are automated (using [[FIT|http://fit.c2.com/]]), but in practice that's rare.\n\nAcceptance tests add real value as a communication tool, showing the developer exactly what is expected of the code they are going to write. This is a powerful tool for eliminating ambiguity, and they make it clear which parts of the system are important and how they will be used. They are also much, much easier to understand (and therefore more likely to be used) than traditional requirements.\n\n!!User acceptance testing\nAll the agile methodologies have true User Acceptance Testing (or Customer Acceptance Testing) - having the end users come and try the software, to give feedback once they see how it really works. In XP, UAT happens every day; in the other methodologies it is done at the end of each iteration. This feedback is a big part of keeping the work focused on real business value, because the business users can adjust the path of a project according to what is actually being developed, not according to a fallible mental model of what someone has described.\n\n!!Co-location\nAll the agile methodologies prescribe co-location (being in the same room) of the analysts and developers, and most want the testers to be in the room also. XP puts the Customer in that room, too. It's very common to see an agile team holed up in a conference room, in order to avoid work in a cube farm. This has an impact in a number of ways: it keeps the team focused on their work, helps the team gel, shortens communication cycles, and lets the team discover and resolve issues extremely quickly. \n

Please see:\n* AnalysisPractices\n* DevelopmentPractices\n* TestingPractices\n* ProjectManagementPractices\n

Crystal, like RUP, is a "methodology framework," but it starts with a "less is more" approach, and actually comes in a few different flavors. CrystalClear, the smallest of the flavors, is a true agile methodology. The other flavors of Crystal are meant to be used when a small agile process isn't appropriate. Each of the flavors is fairly proscriptive about how things should be done, but each also has some room for customization. I don't know much about the specifics, though.\n\nThere's really only one major Crystal resource on the web, and that's [[the inventor's page about it|http://alistair.cockburn.us/crystal/crystal.html]].

I don't know much about DSDM. The acronym stands for "Dynamic Systems Development Method." It's probably the oldest of the methodologies described here, and the most mature. It is more project management focused than XP or Scrum. I think it's less proscriptive about development practices like Pair Programming and Continuous Integration. Otherwise, it may be very similar to the blended version of XP and Scrum that I've been describing here. It is proprietary - you have to pay to license the methodology, from the [[DSDM Consortium|http://www.dsdm.org/]]. \n

I haven't taken the time to write about these, but if you got this far, ask me about:\n* Resource utilization curves\n* Teams should be 6-8 people\n* Eliminating pre-release testing\n* Building a development engine\n* Working with non unit-tested code\n* Practice dependencies (unit tests -> safe to change code -> embrace change)\n

[[Introduction]]\nAgileIntroduction

The agile development practices are the most portable practices; they can all be used with non-agile methodologies. (And thus, doing the development practices does not mean that you're "doing agile".) They are, however, absolutely critical to making agile methodologies work. They are also all self-reinforcing; each of them supports and enables the others. \n\n!!Refactoring (& simplicity)\nRefactoring is very commonly misunderstood to mean "changing the code" or "making the code work the way I want it to" but neither of these is correct. Refactoring is the process of changing the //structure// of the code (usually to make it "simpler") without changing its external behavior. The goal of refactoring is usually to make a new, not-previously-envisioned feature fit well into an existing codebase. This keeps the code flexible (for future changes) and reduces the liklihood of bugs.\n\nRefactoring is often used as an excuse for developers to go clean up code that they're unhappy with. This isn't a good use of refactoring, as it is likely to create bugs without adding any other (immediate) value. Instead, all refactoring should be done as part of new development. \n\nRefactoring is also heavily tied into the idea of "simplicity." XP coined the phrase "do the simplest thing that could possibly work" which is often interpreted as "do the dumbest thing that could possibly work" but really means "keep the design as flexible as possible - don't add anything that you don't need right now." \n\n!!TDD / unit testing\nTDD stands for Test Driven Development or Test Driven Design. It's strongly associated with the "test first" approach to writing code, used by developers:\n# Write a test or set of tests (called "unit tests") that test the functionality they are about to implement.\n## These tests are written as code. There are common tools (such as jUnit) to assist with this process.\n# Run the tests, and see that they fail.\n## Sometimes, they don't fail! This might be because the feature already exists, but more often it's because there is something wrong with the test. That's the point of running them now - make sure that it tests what you think it tests.\n# Implement //just the code required to make the tests pass//, and make sure that it actually does make the tests pass.\n# If you haven't yet completely implemented the feature, begin again (by writing more tests).\n\nThese tests are kept around forever, and maintained as part of the codebase. They are run as part of the build (see Continuous Integration, below). \n\nBut the point of these tests isn't //testing// - it's //designing//, and also reducing the cost-of-change curve (see HistoricalIssues). Writing tests first ensures that the developer only writes the minimum amount of code required to implement a feature, and it almost forces the design to be incredibly flexible. Testable code is also very easy to understand. And a well-tested codebase can be safely refactored, because the tests ensure that the refactoring doesn't break anything. Unit tests do help prevent and catch bugs, but that isn't their primary value.\n\nTDD is a very rich, very complex topic, and more detail will be left to "Agile for Developers" ;)\n\n!!Pair Programming\nPair programming is just what it sounds like - two developers sit together to write the code, sharing a keyboard and a mouse. I believe that XP is the only process that specifically advocates it, but it is generally useful in all methodologies. Pair programming is driven by the cost-of-change curve (see HistoricalIssues) - pairing results in much higher quality code, and therefore reduces the overall cost of development (by avoiding issues that are expensive to fix later in the game). Pairing helps spread knowledge among the developers, because no one person is ever the only expert on an issue. Pairing is also a great way for newer developers to learn from experienced developers. Pairing helps gel a team.\n\nThere are three downsides to pairing, though: \n\nFirst, pairing does slow down the team's rate of code generation. This seems like the obvious result - use two developers to do the work that just one could do, and of course you slow down by half. It turns out that you don't actually slow down by half, because pairs tend to find quicker, simpler ways to implement features. It also turns out that the cost of the slowdown is significantly less than the savings from all the issues/bugs that are avoided because the pair writes better code. \n\nSecond, senior managers and business people often don't understand the value of pairing (because it seems like you only get half the productivity). This can be a problem in numerous ways, and it is difficult to mitigate with the business users in such close contact with the development team. This is more of a political/educational issue than an actual productivity issue.\n\nThird, it's very very hard to pair. Personalities, skill levels, logistics, coding style differences, and design disagreements can all get in the way. Developers generally have to learn to pair well, and it can be a very difficult process. This single issue often makes full-time pairing impossible on a team.\n\n!!Continuous Integration\nThis is a relatively new concept that simply says that developers should integrate their code with all the other developers' code at least once a day. Historically, it was not uncommon for a developer to be working on a feature, off on their own, for weeks or months at a time. When the time came for that developer to merge their code with the rest of the code there were often huge issues, because the rest of the code had been changing while they were off on their own. \n\nContinuous integration basically says "don't do that!" and prescribes that there should be one "master build" that runs every time someone merges their code. That build compiles everyone's (merged) code, runs all the unit tests, and only passes if both steps succeed. It is the merging developer's responsibility to make sure that the build passes whenever they integrate their code.\n\nThis practice significantly reduces the cost of integration, and catches bugs/issues in new code right as the developer was working on it, rather than weeks or months later. Again, this is important because of the cost-of-change curve.

<div class='toolbar' macro='toolbar +saveTiddler -cancelTiddler deleteTiddler'></div>\n<div class='title' macro='view title'></div>\n<div class='editor' macro='edit title'></div>\n<div class='editor' macro='edit text'></div>\n<div class='editor' macro='edit tags'></div>\n<div class='editorFooter'><span macro='message views.editor.tagPrompt'></span><span macro='tagChooser'></span></div>\n

Pure XP is a very tight, very developer-focused, very difficult methodology to use. I would only use pure XP if I had a team of all senior developers, who were also good analysts. But it has lots of great ideas in it. Pure XP is actually not very commonly found in the real world, except as a base for home-grown methodologies, or when merged with a project management-focused methodology like Scrum.\n\nThe roles in XP are:\n* Customer ("The Business")\n* Developer\n* Tester\n* Tracker (tracks metrics, usually done by a developer)\n* Coach (keeps the team from straying from the practices, usually done by a developer)\n\nPure XP doesn't have analysts; the Customer is embedded full-time with the team, and gives developers requirements directly. The Coach role is there to help reinforce the practices (mainly because XP doesn't work unless all the practices are followed). This is an intensely developer-practice-focused methodology, with very proscriptive rules about how things should be done.\n\nTo get a mental model of how XP works, I'd suggest http://www.extremeprogramming.org/\n\nRon Jeffries is probably the most visible of the original XP luminaries; [[his site|http://www.xprogramming.com/]] has lots of real-world practical information (and advertising for his consulting services). \n\nThe [[wikipedia entry|http://en.wikipedia.org/wiki/Extreme_Programming]] on XP is rather good.

FDD is less like a full-blown methodology and more like "here's how to do really good business analysis" and that happens to imply a process, also. Like, XP, it focuses entirely on business value development (XP uses Stories, FDD uses Features). I don't know much beyond that.\n\nThere isn't much FDD information on the web; start with the [[official website|http://www.featuredrivendevelopment.com/]] but from there you'll probably want to buy a book or two.

Historically, there has been a big tension between the fact that requirements are constantly changing and the "fact" that the cost of making changes to software systems rises exponentially with time. That massive cost-of-change curve was the driver behind Waterfall, leading to full, complete specifications before development ever began. The idea behind agile methodologies is to (significanly) reduce the curviness of that curve, so that it is closer to flat. That makes it safer to make change late in a project, and means that we don't need all the analysis up front. That, in turn, allows us to be more responsive to change and deliver software that is much more closely aligned with the real business need.\n\nIt turns out that this effect isn't necessarily the thing that causes agile projects to be cheaper than waterfall projects, though. More often, a side effect of using agile methodologies is that projects simply don't implement all the stuff that isn't really going to add value, and are therefore much smaller.

Welcome to this overview of agile methodologies. Before we begin, please take a moment to familiarize yourself with how this tool works.\n\nThis tool is called a TiddlyWiki, and it is a self-contained [[WikiWikiWeb|http://en.wikipedia.org/wiki/Wiki]]. To learn more about TiddlyWiki, please follow the links in this paragraph. \n\n''Note:'' If you're using Firefox and have the Greasemonkey plugin installed, please disable it. Some parts of this site won't work correctly otherwise. If you're using Internet Explorer, please switch to Firefox. ;) If you must use IE, you may have some problems using this file. Please [[click here|http://www.tiddlywiki.com/#InternetExplorer%20ServicePack2Problems]] to learn more.\n\nOnce you're comfortable with the TiddlyWiki, please go ahead to the AgileIntroduction.\n\n[img[Dilbert - Agile Programming Methods|http://img19.imageshack.us/img19/5645/db2vz.gif]]\n\nIf you want to print every section of this document, please [[click here|#Introduction%20AgileIntroduction%20WhatIsAgile%20ManifestoForAgileSoftwareDevelopment%20PrinciplesBehindTheAgileManifesto%20AgileMindset%20StrengthsAndWeaknesses%20WhenToUseAgile%20HistoricalIssues%20ProcessOverview%20TeamRoles%20AgileTeam%20CommonPractices%20AnalysisPractices%20UserStories%20DevelopmentPractices%20TestingPractices%20ProjectManagementPractices%20DeeperInsights%20AgileResources%20ExtremeProgramming%20Scrum%20CrystalClear%20DSDM%20FeatureDrivenDevelopment%20RUP]] and print the resulting page.\n

AgileIntroduction\n[[The Manifesto|ManifestoForAgileSoftwareDevelopment]]\n[[The Principles|PrinciplesBehindTheAgileManifesto]]\nAgileResources\n\n[[printable version|#Introduction%20AgileIntroduction%20WhatIsAgile%20ManifestoForAgileSoftwareDevelopment%20PrinciplesBehindTheAgileManifesto%20AgileMindset%20StrengthsAndWeaknesses%20WhenToUseAgile%20HistoricalIssues%20ProcessOverview%20TeamRoles%20AgileTeam%20CommonPractices%20AnalysisPractices%20UserStories%20DevelopmentPractices%20TestingPractices%20ProjectManagementPractices%20DeeperInsights%20AgileResources%20ExtremeProgramming%20Scrum%20CrystalClear%20DSDM%20FeatureDrivenDevelopment%20RUP]]\n\nNot seeing the introduction? Please [[disable Greasemonkey|http://www.tiddlywiki.com/#FireFox%20GreaseMonkey]]\n

The Manifesto can always be found at http://www.agilemanifesto.org/, but I've copied it here for reference:\n<<<\nWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: \n* ''Individuals and interactions'' over processes and tools \n* ''Working software'' over comprehensive documentation \n* ''Customer collaboration'' over contract negotiation \n* ''Responding to change'' over following a plan \n\nThat is, while there is value in the items on the right, we value the items on the left more. \n<<<\nAlso see the PrinciplesBehindTheAgileManifesto

Some guy off the street. Comes in and talks about "agile mumbo-jumbo" occasionally.

The Principles can be found at http://www.agilemanifesto.org/principles.html, but I've copied it here for reference:\n<<<\n//We follow these principles: //\n* Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. \n* Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. \n* Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. \n* Business people and developers must work together daily throughout the project. \n* Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. \n* The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. \n* Working software is the primary measure of progress. \n* Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. \n* Continuous attention to technical excellence and good design enhances agility. \n* Simplicity--the art of maximizing the amount of work not done--is essential. \n* The best architectures, requirements, and designs emerge from self-organizing teams. \n* At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. \n<<

We're all familiar with the standard waterfall process:\n# Plan\n# Requirements analysis (and/or use case analysis)\n# Design\n# Code\n# Test\n# Release\n\nAgile methodologies have all these same parts, but they're put into a very different structure. That structure is similar, but not the same, across the methodologies. I've given a fairly generic overview below; please see the diagram that I draw on whiteboards for more detail.\n# Gather high-level stories\n# Plan the first release\n# Start the first release\n## Do a series of fixed-length iterations, where each iteration contains:\n### Story analysis for the next iteration\n### Development (for the current iteration)\n### Acceptance tests (for the current iteration)\n### QA/Test (for the previous iteration)\n## Measure certain metrics after each iteration, and use them to revise the plan\n# When the iterations are complete, release\n# Continuously refine the story list\n# Near the end of the first release, plan the second release \n\nThe real difference between waterfall-like methodologies and agile methodologies lies in the details; this overall process is just the environment in which the important parts happen.\n

!!Stand-up meetings\nScrum and XP specifically advocate that the team has daily stand-up meetings (Scrum calls them "scrums"). The other methodologies may as well; I'm not sure. Everybody on the team (including the Customer) goes to the stand-up, which is actually done standing-up, to keep the meeting from going on too long. (10 minutes is appropriate for a team of 12 people.) Each person gives a very brief update on what they've been working on, what they will be working on, and what they're having trouble with. Some discussion might happen around particular issues, to help people understand the issue or to figure out who knows about it. But the purpose of a stand-up isn't to resolve issues - it's to raise them, and to figure out who the right people are to deal with them, //after// the meeting. \n\nWith stand-up meetings (and co-located teams), regular status meetings become unnecessary. The whole team is informed about what is going on, and problems are identified and addressed no more than 24 hours after they first come up. They are also a good tool for the team to self-regulate - if someone is working on something they shouldn't be, that quickly becomes obvious, and can be corrected. \n\n!!Iterations\nThe most visible difference between traditional methodologies and agile methodologies is the use of iterations. An iteration is a fixed-length unit of work in which a team of developers delivers working business value. Translated into plain English, iterations are (usually) two-week cycles of development in which stories are implemented. \n\nThere are two key parts to the definition. First, iterations are fixed-length, not fixed-scope. If a piece of work (a Story) isn't going to finish in time for the end of an iteration, the iteration finishes without the work. Stories should be sized such that multiple stories (typically 2 for each developer on the team) can be implemented within the iteration. \n\nIterations deliver working business value. By working on stories, developers are automatically focused on working business value. But a partially-complete story doesn't count towards the iteration, and an implementation that couldn't actually be released into production shouldn't be counted as complete. A story that specifies something that couldn't actually be released into production should never have been written ;)\n\nBeyond iterations, agile methodologies all push toward small releases, typically every 2-4 months. This isn't strictly necessary, however; some teams simply release whenever the business tells them to; some release (to production) once a year. \n\n!!Estimation and Velocity\nEstimation is a deep, deep topic, not well suited to an overview. And agile methodologies differ on how estimation and planning should be done. XP uses a very novel approach; Scrum doesn't give an approach; DSDM uses a more traditional approach. (RUP //is// a traditional approach.) Here, I'll give an overview of the XP approach, because it's the form most commonly used in agile processes.\n\nThe novel part of XP estimation is that you don't need accurate estimates to do accurate planning. Instead, you simply measure the difference between the estimate and the (past) reality, and adjust all the future estimates to match. This gives you a realistic picture of how long the remaining work will //really// take. This is also used in the shorter-term to predict how much work will fit into each iteration, by measuring how much work actually fit into the last iteration. This is called "using Yesterday's Weather." \n\nJust to clarify, XP says to do your project planning based on your historical development trends, not based on the actual estimates given to the work. This is much more accurate than the typical waterfall approach of estimating everything before the work begins, and it requires far less work to do.\n\nXP uses the term "velocity," meaning "how much work the team can finish in a given iteration." In other words, if the team was able to complete 800 //estimated hours// of work in the last iteration, their velocity is 800. For the next iteration, assume that the team can do 800 //estimated hours// of work and plan accordingly. This is true regardless of team size.\n\nThis process works with any estimation unit: hours, days, man-weeks, gummi-bears, etc.... so long as the estimation is consistent. If "small" stories are always estimated at 3 gummi-bears, and "large" stories are always estimated at 15 gummi-bears, the velocity calculation will simply output "the team can do 212 gummi-bears of work per iteration" and it can still be used for accurate prediction. The key here, then, is that the estimates are //consistent//, not that they are //accurate// at all, and thus, the problem of inaccurate estimates is avoided.\n\n!!Story backlog and business prioritization\nAs mentioned in AnalysisPractices, agile methodologies almost all use some form of Story Backlog. This backlog is usually just a spreadsheet with a list of all the story titles, and associated with each story is an estimate, a priority, and a status (in scope, out of scope, completed, removed, etc.). On some projects, dependencies (especially external dependencies) come into play, and are tracked in the backlog. Additional data may be captured (see Metrics, below) but isn't strictly necessary. \n\nThe backlog is a living list, changed almost daily as stories are added, removed, split, implemented, estimated, etc. \n\nThe story priorities are usually kept as an ordered list (1, 2, 3, 4, ...), rather than as high/medium/low. This forces the business to make real tradeoffs about what is most important, and lets the project manager plan the work. The priorities are owned by the business, though, and they usually re-prioritize after each iteration. \n\nThe backlog answers the two most important project management questions: "What's next?" and "When will we finish?" The "What's next?" question is answered by adding up the estimates of all the highest-priority stories, until there is no room for more stories in the next iteration. The "When will we finish?" question is answered by adding up all the estimates of the not-yet-completed in-scope stories, and dividing by the velocity. That's it - that's all there is to answering those two questions.\n\nThere is a third interesting question: "How long will it take until we finish X?" This question is often asked by the business when faced with an approaching release date or a limited budget. Again, this question is easy to answer - simply add up the estimates of the stories that come before X, and divide by the velocity. If the answer isn't satisfactory, reprioritize the stories until it is (or admit defeat). \n\n!!The Card Wall\nLast, but not least, is an interesting practice that comes from XP: the use of a Card Wall. The idea is that you divide a wall up into sections each labeled with a status. (Typical statuses are: Backlog, In Progress, Acceptance Test, QA, Done.) Then you write the title of the stories for the current iteration on a 3x5 card and put all the cards in the Backlog section. \n\nAs the developers begin work on a story, they move the card over to the In Progress section, and when they finish they move it to Acceptance Test. When the analyst has reviewed the implementation, they either move the card back (with comments) or forward (to QA). QA then moves the card appropriately, also. \n\nSome teams use different card colors to mean different things, like what type of story it represents, what iteration is was originally from, etc. Usually the analysts, developers, and testers will write their names on cards they worked on, so it's easy to figure out who did (or is doing) what. \n\nThe value of the wall is two-fold. First, it's a great way to keep the whole team aware of how the iteration is running, and how much work is left to be done. Second, it gives the team something physical to look at, draw on, pass around, point at, etc. This makes it a lot easer to re-prioritize, or to see who is backed up with what, or to figure out what didn't get done. \n\nYou can see an example of a card wall in [[James Shore's article about story cards|http://jamesshore.com/Presentations/Beyond%20Story%20Cards.html]].\n

RUP is more of a "methodology framework" than an actual methodology - think of it as a toolbox full of tools (artifacts / process) that you can pick from to design the process you need for a particular project or organization. RUP throws just about everything into the toolbox, so the tendency is to have more process, not less. Usually RUP is implemented with Use Cases and long (3-6 month) "iterations" that are really more like standard waterfall projects. It is possible to design a ~RUP-based process that fits the ManifestoForAgileSoftwareDevelopment, but I've never heard of it actually happening.\n\nIf you want to learn more, it seems safest to start with the [[wikipedia entry|http://en.wikipedia.org/wiki/RUP]]

The roles in Scrum are:\n* Product Owner ("The Customer")\n* Team Member (Analysts, Developers, and Testers)\n* Scrum Master ("Project Manager")\n\nScrum is heavily focused on the project management processes, and abstracts away the development roles (analyst / developer / tester). It also insists that people shouldn't be put into those specific roles, and that the team shares responsibility for nearly all aspects of a project. The Scrum Master is not like a typical Project Manager, in that their job is simply to remove obstacles, not to manage the team. In practice, teams fall into their usual roles (and I haven't see this be a bad thing).\n\nScrum is actually a very simple methodology, that only prescribes a few things:\n* 1-month iterations with a few carefully-designed meetings\n* Daily stand-up meetings\n* A Story Backlog (or just "Backlog")\n* Plan as you go, or not at all (Scrum argues that software development is a chaotic process and that you can't plan it - you can just navigate it)\n* The team is responsible for everything\n* The Scrum Master is responsible for getting things out of the team's way\n* The Product Owner is responsible for all feature decisions\n\nThe best place to get an overview is probably [[the wikipedia entry|http://en.wikipedia.org/wiki/Scrum_%28management%29]]. [[Mountain Goat Software's page|http://www.mountaingoatsoftware.com/scrum/]] is very handy, and the [[official scrum site|http://www.controlchaos.com/]] can be helpful.\n

<<tabs txtMainTab Timeline Timeline TabTimeline All 'All tiddlers' TabAll More 'More lists' TabMore>>

a brief overview of agile methodologies

Agile for Managers

The real question, of course, is "why would I want to use an Agile methodology?" There are a lot of reasons, but the common (purported) reasons are:\n* The ability to respond to changing business conditions in near-real-time - on the order of weeks, not months or years\n* Higher quality software, in terms of suitability-to-purpose and in terms of defect count\n* Higher accuracy in planning\n* More productive teams\n* Happier teams\n* Distributed knowledge, so the project isn't dependent on specific individuals\n* Fast discovery of bad projects (fail-fast)\n\nThere are a number of downsides, though. The various agile methodologies do different things to address these, but most of them apply to most of the methodologies:\n* Pair programming is very hard to get right\n* It's easy to miss non-functional requirements\n* There isn't much documentation\n* Hard to implement on an untested codebase\n* Hard to scale to larger teams and larger projects\n* Agile isn't suited to all projects - see WhenToUseAgile\n* XP (especially) breaks down when done half-heartedly\n

/***\n!Colors Used\n*@@bgcolor(#8cf): #8cf - Background blue@@\n*@@bgcolor(#18f): #18f - Top blue@@\n*@@bgcolor(#04b): #04b - Mid blue@@\n*@@bgcolor(#014):color(#fff): #014 - Bottom blue@@\n*@@bgcolor(#ffc): #ffc - Bright yellow@@\n*@@bgcolor(#fe8): #fe8 - Highlight yellow@@\n*@@bgcolor(#db4): #db4 - Background yellow@@\n*@@bgcolor(#841): #841 - Border yellow@@\n*@@bgcolor(#703):color(#fff): #703 - Title red@@\n*@@bgcolor(#866): #866 - Subtitle grey@@\n!Generic Rules /%==============================================%/\n***/\n/*{{{*/\nbody {\n background: #fff;\n color: #000;\n}\n\na{\n color: #04b;\n}\n\na:hover{\n background: #04b;\n color: #fff;\n}\n\na img{\n border: 0;\n}\n\n.button {\n color: #014;\n border: 1px solid #fff;\n}\n\n.button:hover {\n color: #014;\n background: #fe8;\n border: 1px solid #db4;\n}\n\n.button:active {\n color: #fff;\n background: #db4;\n border: 1px solid #841;\n}\n\n/*}}}*/\n/***\n!Header /%==================================================%/\n***/\n/*{{{*/\n.header {\n background: #04b;\n}\n\n.headerShadow {\n color: #000;\n}\n\n.headerShadow a {\n font-weight: normal;\n color: #000;\n}\n\n.headerForeground {\n color: #fff;\n}\n\n.headerForeground a {\n font-weight: normal;\n color: #8cf;\n}\n\n/*}}}*/\n/***\n!General tabs /%=================================================%/\n***/\n/*{{{*/\n\n.tabSelected{\n color: #014;\n background: #eee;\n border-left: 1px solid #ccc;\n border-top: 1px solid #ccc;\n border-right: 1px solid #ccc;\n}\n\n.tabUnselected {\n color: #fff;\n background: #999;\n}\n\n.tabContents {\n color: #014;\n background: #eee;\n border: 1px solid #ccc;\n}\n\n.tabContents .button {\n border: 0;}\n\n/*}}}*/\n/***\n!Sidebar options /%=================================================%/\n~TiddlyLinks and buttons are treated identically in the sidebar and slider panel\n***/\n/*{{{*/\n#sidebar {\n}\n\n#sidebarOptions input {\n border: 1px solid #04b;\n}\n\n#sidebarOptions .sliderPanel {\n background: #8cf;\n}\n\n#sidebarOptions .sliderPanel a {\n border: none;\n color: #04b;\n}\n\n#sidebarOptions .sliderPanel a:hover {\n color: #fff;\n background: #04b;\n}\n\n#sidebarOptions .sliderPanel a:active {\n color: #04b;\n background: #fff;\n}\n/*}}}*/\n/***\n!Message Area /%=================================================%/\n***/\n/*{{{*/\n#messageArea {\n border: 1px solid #841;\n background: #db4;\n color: #014;\n}\n\n#messageArea .button {\n padding: 0.2em 0.2em 0.2em 0.2em;\n color: #014;\n background: #fff;\n}\n\n/*}}}*/\n/***\n!Popup /%=================================================%/\n***/\n/*{{{*/\n.popup {\n background: #18f;\n border: 1px solid #04b;\n}\n\n.popup hr {\n color: #014;\n background: #014;\n border-bottom: 1px;\n}\n\n.popup li.disabled {\n color: #04b;\n}\n\n.popup li a, .popup li a:visited {\n color: #eee;\n border: none;\n}\n\n.popup li a:hover {\n background: #014;\n color: #fff;\n border: none;\n}\n/*}}}*/\n/***\n!Tiddler Display /%=================================================%/\n***/\n/*{{{*/\n\n.tiddler .defaultCommand {\n font-weight: bold;\n}\n\n.shadow .title {\n color: #866;\n}\n\n.title {\n color: #703;\n}\n\n.subtitle {\n color: #866;\n}\n\n.toolbar {\n color: #04b;\n}\n\n.tagging, .tagged {\n border: 1px solid #eee;\n background-color: #eee;\n}\n\n.selected .tagging, .selected .tagged {\n background-color: #ddd;\n border: 1px solid #bbb;\n}\n\n.tagging .listTitle, .tagged .listTitle {\n color: #014;\n}\n\n.tagging .button, .tagged .button {\n border: none;\n}\n\n.footer {\n color: #ddd;\n}\n\n.selected .footer {\n color: #888;\n}\n\n.sparkline {\n background: #8cf;\n border: 0;\n}\n\n.sparktick {\n background: #014;\n}\n\n.errorButton {\n color: #ff0;\n background: #f00;\n}\n\n.cascade {\n background: #eef;\n color: #aac;\n border: 1px solid #aac;\n}\n\n.imageLink, #displayArea .imageLink {\n background: transparent;\n}\n\n/*}}}*/\n/***\n''The viewer is where the tiddler content is displayed'' /%------------------------------------------------%/\n***/\n/*{{{*/\n\n.viewer {\n border-bottom: 1px solid #AAA;\n}\n\n.viewer .listTitle {list-style-type: none; margin-left: -2em;}\n\n.viewer .button {\n border: 1px solid #db4;\n}\n\n.viewer blockquote {\n border-left: 3px solid #666;\n}\n\n.viewer table {\n border: 2px solid #333;\n}\n\n.viewer th, thead td {\n background: #996;\n border: 1px solid #666;\n color: #fff;\n}\n\n.viewer td, .viewer tr {\n border: 1px solid #666;\n}\n\n.viewer pre {\n border: 1px solid #fe8;\n background: #ffc;\n}\n\n.viewer code {\n color: #703;\n}\n\n.viewer hr {\n border: 0;\n border-top: dashed 1px #666;\n color: #666;\n}\n\n.highlight, .marked {\n background: #fe8;\n}\n/*}}}*/\n/***\n''The editor replaces the viewer in the tiddler'' /%------------------------------------------------%/\n***/\n/*{{{*/\n.editor input {\n border: 1px solid #04b;\n}\n\n.editor textarea {\n border: 1px solid #04b;\n width: 100%;\n}\n\n.editorFooter {\n color: #aaa;\n}\n\n/*}}}*/

/***\n!Sections in this Tiddler:\n*Generic rules\n**Links styles\n**Link Exceptions\n*Header\n*Main menu\n*Sidebar\n**Sidebar options\n**Sidebar tabs\n*Message area\n*Popup\n*Tabs\n*Tiddler display\n**Viewer\n**Editor\n*Misc. rules\n!Generic Rules /%==============================================%/\n***/\n/*{{{*/\nbody {\n font-size: .75em;\n font-family: arial,helvetica;\n position: relative;\n margin: 0;\n padding: 0;\n}\n\nh1,h2,h3,h4,h5 {\n font-weight: bold;\n text-decoration: none;\n padding-bottom: 0;\n margin-bottom: 0;\n}\n\nh1 {font-size: 1.35em;}\nh2 {font-size: 1.25em;}\nh3 {font-size: 1.1em;}\nh4 {font-size: 1em;}\nh5 {font-size: .9em;}\n\nhr {\n height: 1px;\n}\n\na{\n text-decoration: none;\n}\n\nol { list-style-type: decimal }\nol ol { list-style-type: lower-alpha }\nol ol ol { list-style-type: lower-roman }\nol ol ol ol { list-style-type: decimal }\nol ol ol ol ol { list-style-type: lower-alpha }\nol ol ol ol ol ol { list-style-type: lower-roman }\nol ol ol ol ol ol ol { list-style-type: decimal }\n/*}}}*/\n/***\n''General Link Styles'' /%-----------------------------------------------------------------------------%/\n***/\n/*{{{*/\n.externalLink {\n text-decoration: underline;\n}\n\n.tiddlyLinkExisting {\n font-weight: bold;\n}\n\n.tiddlyLinkNonExisting {\n font-style: italic;\n}\n\n/* the 'a' is required for IE, otherwise it renders the whole tiddler a bold */\na.tiddlyLinkNonExisting.shadow {\n font-weight: bold;\n}\n/*}}}*/\n/***\n''Exceptions to common link styles'' /%------------------------------------------------------------------%/\n***/\n/*{{{*/\n\n#mainMenu .tiddlyLinkExisting, \n#mainMenu .tiddlyLinkNonExisting,\n#sidebarTabs .tiddlyLinkExisting,\n#sidebarTabs .tiddlyLinkNonExisting,\n#siteTitle .tiddlyLinkExisting,\n#siteTitle .tiddlyLinkNonExisting{\n font-weight: normal;\n font-style: normal;\n}\n\n/*}}}*/\n/***\n!Header /%==================================================%/\n***/\n/*{{{*/\n\n.header {\n position: relative;\n}\n\n.header a:hover {\n background: transparent;\n}\n\n.headerShadow {\n position: relative;\n padding: 4.5em 0em 1em 1em;\n left: -1px;\n top: -1px;\n}\n\n.headerForeground {\n position: absolute;\n padding: 4.5em 0em 1em 1em;\n left: 0px;\n top: 0px;\n}\n\n.siteTitle {\n font-size: 3em;\n}\n\n.siteSubtitle {\n font-size: 1.2em;\n}\n\n/*}}}*/\n/***\n!Main menu /%==================================================%/\n***/\n/*{{{*/\n#mainMenu {\n position: absolute;\n left: 0;\n width: 10em;\n text-align: right;\n line-height: 1.6em;\n padding: 1.5em 0.5em 0.5em 0.5em;\n font-size: 1.1em;\n}\n\n/*}}}*/\n/***\n!Sidebar rules /%==================================================%/\n***/\n/*{{{*/\n#sidebar {\n position: absolute;\n right: 3px;\n width: 16em;\n font-size: .9em;\n}\n/*}}}*/\n/***\n''Sidebar options'' /%----------------------------------------------------------------------------------%/\n***/\n/*{{{*/\n#sidebarOptions {\n padding-top: 0.3em;\n}\n\n#sidebarOptions a {\n margin: 0em 0.2em;\n padding: 0.2em 0.3em;\n display: block;\n}\n\n#sidebarOptions input {\n margin: 0.4em 0.5em;\n}\n\n#sidebarOptions .sliderPanel {\n margin-left: 1em;\n padding: 0.5em;\n font-size: .85em;\n}\n\n#sidebarOptions .sliderPanel a {\n font-weight: bold;\n display: inline;\n padding: 0;\n}\n\n#sidebarOptions .sliderPanel input {\n margin: 0 0 .3em 0;\n}\n/*}}}*/\n/***\n''Sidebar tabs'' /%-------------------------------------------------------------------------------------%/\n***/\n/*{{{*/\n\n#sidebarTabs .tabContents {\n width: 15em;\n overflow: hidden;\n}\n\n/*}}}*/\n/***\n!Message area /%==================================================%/\n***/\n/*{{{*/\n#messageArea {\nposition:absolute; top:0; right:0; margin: 0.5em; padding: 0.5em;\n}\n\n*[id='messageArea'] {\nposition:fixed !important; z-index:99;}\n\n.messageToolbar {\ndisplay: block;\ntext-align: right;\n}\n\n#messageArea a{\n text-decoration: underline;\n}\n/*}}}*/\n/***\n!Popup /%==================================================%/\n***/\n/*{{{*/\n.popup {\n font-size: .9em;\n padding: 0.2em;\n list-style: none;\n margin: 0;\n}\n\n.popup hr {\n display: block;\n height: 1px;\n width: auto;\n padding: 0;\n margin: 0.2em 0em;\n}\n\n.popup li.disabled {\n padding: 0.2em;\n}\n\n.popup li a{\n display: block;\n padding: 0.2em;\n}\n/*}}}*/\n/***\n!Tabs /%==================================================%/\n***/\n/*{{{*/\n.tabset {\n padding: 1em 0em 0em 0.5em;\n}\n\n.tab {\n margin: 0em 0em 0em 0.25em;\n padding: 2px;\n}\n\n.tabContents {\n padding: 0.5em;\n}\n\n.tabContents ul, .tabContents ol {\n margin: 0;\n padding: 0;\n}\n\n.tabContents li {\n list-style: none;\n}\n\n.tabContents li.listLink {\n margin-left: .75em;\n}\n/*}}}*/\n/***\n!Tiddler display rules /%==================================================%/\n***/\n/*{{{*/\n#displayArea {\n margin: 1em 17em 0em 14em;\n}\n\n.toolbar {\n text-align: right;\n font-size: .9em;\n visibility: hidden;\n}\n\n.selected .toolbar {\n visibility: visible;\n}\n\n.missing .viewer,.missing .title {\n font-style: italic;\n}\n\n.title {\n font-size: 1.6em;\n font-weight: bold;\n}\n\n.missing .subtitle {\n display: none;\n}\n\n.subtitle {\n font-size: 1.1em;\n}\n\n/* I'm not a fan of how button looks in tiddlers... */\n.tiddler .button {\n padding: 0.2em 0.4em;\n}\n\n.tagging {\nmargin: 0.5em 0.5em 0.5em 0;\nfloat: left;\ndisplay: none;\n}\n\n.isTag .tagging {\ndisplay: block;\n}\n\n.tagged {\nmargin: 0.5em;\nfloat: right;\n}\n\n.tagging, .tagged {\nfont-size: 0.9em;\npadding: 0.25em;\n}\n\n.tagging ul, .tagged ul {\nlist-style: none;margin: 0.25em;\npadding: 0;\n}\n\n.tagClear {\nclear: both;\n}\n\n.footer {\n font-size: .9em;\n}\n\n.footer li {\ndisplay: inline;\n}\n/***\n''The viewer is where the tiddler content is displayed'' /%------------------------------------------------%/\n***/\n/*{{{*/\n* html .viewer pre {\n width: 99%;\n padding: 0 0 1em 0;\n}\n\n.viewer {\n line-height: 1.4em;\n padding-top: 0.5em;\n padding-bottom: 1em;\n}\n\n.viewer .button {\n margin: 0em 0.25em;\n padding: 0em 0.25em;\n}\n\n.viewer blockquote {\n line-height: 1.5em;\n padding-left: 0.8em;\n margin-left: 2.5em;\n}\n\n.viewer ul, .viewer ol{\n margin-left: 0.5em;\n padding-left: 1.5em;\n margin-bottom: 0;\n padding-bottom: 0;\n}\n\n.viewer table {\n border-collapse: collapse;\n margin: 0.8em 1.0em;\n}\n\n.viewer th, .viewer td, .viewer tr,.viewer caption{\n padding: 3px;\n}\n\n.viewer pre {\n padding: 0.5em;\n margin-left: 0.5em;\n font-size: 1.2em;\n line-height: 1.4em;\n overflow: auto;\n}\n\n.viewer code {\n font-size: 1.2em;\n line-height: 1.4em;\n}\n/*}}}*/\n/***\n''The editor replaces the viewer in the tiddler'' /%------------------------------------------------%/\n***/\n/*{{{*/\n.editor {\nfont-size: 1.1em;\n}\n\n.editor input, .editor textarea {\n display: block;\n width: 100%;\n font: inherit;\n}\n\n.editorFooter {\n padding: 0.25em 0em;\n font-size: .9em;\n}\n\n.editorFooter .button {\npadding-top: 0px; padding-bottom: 0px;}\n\n.fieldsetFix {border: 0;\npadding: 0;\nmargin: 1px 0px 1px 0px;\n}\n/*}}}*/\n/***\n!Misc rules /%==================================================%/\n***/\n/*{{{*/\n.sparkline {\n line-height: 1em;\n}\n\n.sparktick {\n outline: 0;\n}\n\n.zoomer {\n font-size: 1.1em;\n position: absolute;\n padding: 1em;\n}\n\n.cascade {\n font-size: 1.1em;\n position: absolute;\n overflow: hidden;\n}\n/*}}}*/

config.options.chkHttpReadOnly = true;

The different agile methodologies have different defined roles. In practice, the primary roles on an AgileTeam always turn out to be:\n* The Business or Customer\n* Analyst\n* Developer\n* Tester\n* Project Manager\n\n(Seem familiar?) Additional roles (ex: Build Manager) are thrown in as needed. "Architect" tends to be a cussword and ~DBAs are rare. \n\nIn practice, the practices of each methodology usually divide along role boundaries, giving us:\n* AnalysisPractices\n* DevelopmentPractices\n* TestingPractices\n* ProjectManagementPractices\n

"Agile testing," as a topic, is almost a non-entity. XP advocates that most of the testing is done by developers; Scrum doesn't discuss testing in any depth at all; RUP doesn't say anything about testing that hasn't already been said in Waterfall. But there are differences about testing in an agile methodology, and those differences are significant.\n\nIn an agile process, testing is done iteration-by-iteration rather than release-by-release. That means that testing is done in smaller batches, and on code that was more recently developed, both of which have obvious benefits. It also means that regression tests are run more often, again with obvious benefits. \n\nThese benefits, however, come with a "cost" - in order to perform full regression testing that often, it has to be automated. Thus testing in an agile process really means "writing automated tests," and there is usually only a small amount of (expensive-to-automate) manual testing. \n\nThis can seem like a daunting proposition, but there are a number of good testing tools for doing this (like [[FIT|http://fit.c2.com/]]), and the benefits are huge. Teams that have a full (and growing) suite of automated tests rarely realease any production bugs (yes, I said "0"). And the cost of implementing these tests is actually comparable to the cost of doing full manual regression testing, because it spread out over the course of the release and can be done by a comparably small number of people. \n\nOtherwise, testing is about the same. The usual suite of testing types (regression, performance, integration, installation, etc.) still apply. It is still possible to ignore good test practices and release a working (but buggy) codebase. Testing remains a skill that requires expertise and the right mindset.

This file is a TiddlyWiki. Learn more about it at http://www.tiddlywiki.com/ or read the tutorial at http://www.blogjones.com/TiddlyWikiTutorial.html.

The use of Stories in agile methodologies is complex and controversial. The basic idea behind using stories (instead of requirements or use cases) is that they keep the focus on real user/business needs and that they aren't a complete specification of functionality. In pure XP, a story is literally written on a 3x5 card (so there isn't room for a lot of detail), and it just serves as "a reminder to have a conversation." In practice, most stories are written as Word documents although they are sometimes written directly in wiki pages. The set of suggested story templates is a diverse as the set of suggested requirements templates. I have a personal standard that I've had great success with, containing just these sections:\n* Author (the analyst, usually)\n* Title (something that could be written on a 3x5 card)\n* Narrative\n** This section contains whatever text the analyst feels is appropriate to describe the story. The only rule is that the narrative should begin with a sentence of the form "As xxx I want yyy so that zzz." This form ensures that it's clear who the user is, what //they// want, and why they want it. There's a lot of depth around this sentence, but that's a topic for "Agile for Analysts" ;)\n* Acceptance Criteria\n** This section contains the real value of a story - a set of step-by-step acceptance tests that will be used to validate that the story //does what the user wants it to do//. These tests are a fantastic communication tool, showing the developer exactly what is expected of the code they are going to write.\n* Other (a handy place to throw information that didn't fit anywhere else)\n\nStories should be implementable within a single iteration (1-4 weeks, typically). Some agile practitioners prescribe that all stories must be business-focused, but that's a very difficult constraint to meet. Stories can be split, changed, or thrown out at any point up until the time they are implemented. Once they are implemented, they can be thrown away.\n\nStories are collected in a backlog, which is usually a spreadsheet. (XP would advocate a stack of cards.) The backlog is used to drive the project. Priorities and estimates are tracked here, as is the completion-status of each story. Stories can be added or removed or taken out-of-scope at will, and that affects the overall scope of the project. The backlog is continually answering the questions "what's next?" and "how much is left?". Please see ProjectManagementPractices for more detail.\n

<div class='toolbar' macro='toolbar +editTiddler permalink references jump closeOthers -closeTiddler'></div>\n<div class='title' macro='view title'></div>\n<div class='subtitle'><span macro='view modifier link'></span>, <span macro='view modified date [[DD MMM YYYY]]'></span> (created <span macro='view created date [[DD MMM YYYY]]'></span>)</div>\n<div class='viewer' macro='view text wikified'></div>\n<div class='tagClear'></div>

"Agile" is a generic term for a spectrum of methodologies that all share some common traits, including:\n* Close collaboration between the business and the developers\n* Face-to-face communication, instead of documentation\n* Iterative and incremental delivery of actual business value\n* Tight, self-organizing teams\n* Responsiveness and (glad!) acceptance of requirements change\n\nThat spectrum I mentioned is actually two-dimensional; one dimension describes how iterative the methodology is (from 1-week iterations to multi-month iterations), and the other describes whether the methodology is focused on developer practices or project management practices (or both). Here's how I'd place them:\n\n|! |!< Smaller iterations |!   |! Larger iterations >|\n|!^ Development-centric | ExtremeProgramming (XP) | | |\n|!  | CrystalClear | [[DSDM]], FeatureDrivenDevelopment | |\n|!v Project management-centric | | [[Scrum]] | [[RUP]] |\n\nI've used XP, Scrum, RUP, and a blended version of XP and Scrum. Note that RUP isn't usually considered an agile methodology, but some people say it is. This document will be focused on the specific mothodologies I have experience with - I can't say definitive things about the others (Crystal, DSDM, FDD), but they are also less common today.\n\nMore generically, though, there is a published ManifestoForAgileSoftwareDevelopment and PrinciplesBehindTheAgileManifesto. These two documents give a glimpse of the AgileMindset - the real paradigm shift in thinking that comes once you [[grok|http://en.wikipedia.org/wiki/Grok]] the ideas behind agile. \n

Agile is not for all projects. A lot of the practices in agile methodologies are designed around high-risk, highly-volatile projects, and doing all the practices on a small, low-risk project might simply slow you down. To that end, here's a set of attributes that indicate that you should consider agile methodologies:\n* Changing requirements\n* High risk\n* New domain\n* Large projects\n* Experienced team\n\n...and here's a set that indicate that agile is probably not a good fit:\n* Stable requirements\n* Low risk\n* Familiar domain / environment\n* Short/small projects\n* Inexperienced team