10 Key Principles of Agile Development by Kelly Waters, 10 February 2007 | 10 Key Principles of Agile Development Agile Development is one

of the big buzzwords of the software development industry. But what exactly is agile development? Agile development is a different way of managing software development projects. 10 Key Principles of Agile... read more Agile Principle 1: Active User Involvement Is Imperative by Kelly Waters, 24 February 2007 10 Key Principles of Agile Development In my mind, active user involvement is the first principle of agile developm ent. It's not always possible to have users directly involved in development projects, particularly if... read more Agile Principle 2: Agile Development Teams Must Be Empowered by Kelly Waters, 4 March 2007 10 Key Principles of Agile Development An agile development team must include all the necessary team members to make decisions, and make them on a timely basis. Active user involvement is one of the key principles to... read more Agile Principle 3: Time Waits For No Man! by Kelly Waters, 11 March 2007 10 Key Principles of Agile Development In agile development, requirements evolve, but timescales are fixed. This is in stark contrast to a traditional development project, where one of the earliest goals is to capture... read more Agile Principle 4: Agile Requirements Are Barely Sufficient by Kelly Waters, 17 March 2007 10 Key Principles of Agile Development Agile development teams capture requirements at a high level and on a piecemeal basis, just-intime for each feature to be developed. Agile requirements are ideally visual and should... read more Agile Principle 5: How Do You Eat An Elephant? by Kelly Waters, 25 March 2007 10 Key Principles of Agile Development

How do you eat an elephant? One bite at a time! Likewise, agile development projects are delivered in small bite-sized pieces, delivering small, incremental *releases* and iterating. In... read more Agile Principle 6: Fast But Not So Furious by Kelly Waters, 31 March 2007 10 Key Principles of Agile Development Agile development is all about frequent delivery of products. In a truly agil e world, gone are the days of the 12 month project. In an agile world, a 3 -6 month project is strategic! Nowhere... read more Agile Principle 7: Done Means DONE! by Kelly Waters, 8 April 2007 10 Key Principles of Agile Development In agile development, "done" should really mean "DONE!". Features developed within an iteration (Sprint in Scrum), should be 100% complete by the end of the Sprint. Too often... read more Agile Principle 8: Enough Is Enough! by Kelly Waters, 15 April 2007 10 Key Principles of Agile Development Pareto's law is more commonly known as the 80/20 rule. The theory is about th e law of distribution and how many things have a similar distribution curve. This means that *typically*... read more Agile Principle 9: Agile Testing Is Not For Dummies! by Kelly Waters, 22 April 2007 10 Key Principles of Agile Development In agile development, testing is integrated throughout the lifecycle; testing the software continuously throughout its development. Agile development does not have a separate test... read more Agile Principle 10: No Place For Snipers! by Kelly Waters, 30 April 2007 10 Key Principles of Agile Development Agile development relies on close cooperation and collaboration between all team members and stakeholders. Agile development principles include keeping requirements and documentation... read more

Agile Principle 1: Active User Involvement Is Imperative

by Kelly Waters, 24 February 2007 | 10 Key Principles of Agile Development

In my mind, active user involvement is the first principle of agile development. It s not always possible to have users directly involved in development projects, particularly if the agile development project is to build a product where the real end users will be external customers or consumers. In this event it is imperative to have a senior and experienced user representative involved throughout. Not convinced? Here s 16 reasons why!
y y y y y y y y y y y y y y y y

Requirements are clearly communicated and understood (at a high level) at the outset Requirements are prioritised appropriately based on the needs of the user and market Requirements can be clarified on a daily basis with the entire project team, rather than resorting to lengthy documents that aren t read or are misunderstood Emerging requirements can be factored into the development schedule as appropriate with the impact and trade-off decisions clearly understood The right product is delivered As iterations of the product are delivered, that the product meets user expectations The product is more intuitive and easy to use The user/business is seen to be interested in the development on a daily basis The user/business sees the commitment of the team Developers are accountable, sharing progress openly with the user/business every day There is complete transparency as there is nothing to hide The user/business shares responsibility for issues arising in development; it s not a customersupplier relationship but a joint team effort Timely decisions can be made, about features, priorities, issues, and when the product is ready Responsibility is shared; the team is responsible together for delivery of the product Individuals are accountable, reporting for themselves in daily updates that involve the user/business When the going gets tough, the whole team business and technical work together! Kelly.

See als : 10 Key Pri i les of Agile Development

8 Mar h 2007 at 6: 2 pm There should be no users in agile. The results of agile should be so pervasive to an individual s needs that the produ t is an appendage to their needs. hen was the last time you read a user guide or specified user requirements for your arm or leg? On a slightly different note, involvement of any individuals is simply part of a full series of activities involved in Design Research . The artifacts of Design Research are the elements used to support Evidence-Based Design . 2. Kelly Water says: 16 March 2007 at 8:47 am I don t agree with this comment. Although scrum team is a *team* and the project goals are *team goals*, there must be a user role in the team. Although everyone should care about the user, someone must have specific knowledge and understanding of the user s needs, because a software product with no users has no value. 3. StephenKress says: 22 March 2007 at 11:31 pm I also disagree. There are no requirements for an arm or a leg, because you just get one. You don t have a choice, you just get one (if you re lucky). ow can you design something that is Pervasive to an individual s needs if you don t have a user to design for? Since there are always several ways to implement how a user interacts with an IT system, you shouldn t count on the designer to choose the right way. You must ask a user (and better yet, ask many users). 4. Scott W, Ambler says: 28 March 2007 at 12:51 am The real issue is active stakeholder participation, not just active user involvement. A few thoughts: 1. Users are just one of many stakeholders, important ones obviously, but not your only ones. If

1.

Paula Thor to says:

7 Resp

ses to A ile Pri ciple 1: Acti e User Involvement Is Imper tive

you ignore other stakeholders you put your project at risk. 2. Participation is better than simple involvement. If you don t find ways to enable them to actively participate you put your project at risk. Not only should stakeholders provide information and make decisions in a timely manner, they should also actively participate in the modeling effort themselves. You can do this by adopting inclusive modeling tools such as whiteboards and paper. In Agile Modeling we made this very clear and included an explicit practice, Active Stakeholder Participation. There s a detailed article on this at http://www.agilemodeling.com/essays /activeStakeholderParticipation.htm There s also a detailed article on inclusive modeling at http://www.agilemodeling.com/essays /inclusiveModels.htm . Enjoy! - Scott 5. wh rliwig says: 29 April 2007 at 12:16 pm Another disagree vote although there is a sense in which removing the traditional concept of user as a them , as opposed to us , is useful. Actually, I d love to have a user guide for my arms and legs. Unfortunately there s no-one qualified to write it. I have to make do with user guides for less customised versions of my arms and legs: health articles on the internet, medical encyclopaedias etc and if I get in real trouble I have to go see a developer (sorry, doctor ) unfortunately I didn t negotiate the contract properly, so I often have to wait for weeks for an appointment 6. Wouter says: 8 January 2009 at 3:45 pm I think Paula was not talking about agile development method, but more about the philosophy behind it. That the end product should be so intuitive to use for the user, that he does not feel like a user, but is just doing what he does. If i understand her correctly, i m sure that she agrees that this requires a very deep understanding of the user. I don t think tho, that agile has failed if this is not reached. Agile has worked, if the end-user is happy with the product, even if it comes with a manual. 7. JObermark says: 22 March 2009 at 4:49 pm It is also mandatory that this user representative is part of the team, and not a taskmaster we are all serving. Presumed functionality preconceived in complete detail are not needs.

It is not uncommon for this supposed team member to sneak off and plan out detailed task-lists for months in the future, and then try to shape the present development around these visions of the future, rather than around identifiable needs that can be completely nailed down. Agile folks focus on not identifying our user as alien and disconnected, but we also need to sell the idea that we are not a them to the rest if the institution. We need to continually be clear that a team is a team, and a player who wishes to be the referee is unwelcome.

Agile Principle 2: Agile Development Teams Must Be Empowered

by Kelly Waters, 4 March 2007 | 10 Key Principles of Agile Development

An agile development team must include all the necessary team members to make decisions, and make them on a timely basis. Active user involvement is one of the key principles to enable this, so the user or user representative from the business must be closely involved on a daily basis. The project team must be empowered to make decisions in order to ensure that it is their responsibility to deliver the product and that they have complete ownership. Any interference with the project team is disruptive and reduces their motivation to deliver. The team must establish and clarify the requirements together, prioritise them together, agree to the tasks required to deliver them together, and estimate the effort involved together. It may seem expedient to skip this level of team involvement at the beginning. It s tempting to get a subset of the team to do this (maybe just the product owner and analyst), beca use it s much more efficient. Somehow we ve all been trained over the years that we must be 100% efficient (or more!) and having the whole team involved in these kick-off steps seems a very expensive way to do things. However this is a key principle for me. It ensures the buy-in and commitment from the entire project team from the outset; something that later pays dividends. When challenges arise throughout the project, the team feels a real sense of ownership. And then it s doesn t seem so expensive. Kelly.

See also: 10 Key Principles of Agile Development

5 Responses to A ile Principle 2: A ile Development Teams Must Be Empowered 1. IAmGM1974 says: 17 January 2008 at 12:00 am I understand that there has to be a buy-in from all the team, but at times I have observed that if everyone is involved into a discussion, sometimes people start pulling the discussion in different directions and it becomes difficult to reach a conclusion. My question is, and I may be very wrong, but: Could it make sense, at least in very initial stages to have a sort of pre-meeting where, say the product owner, users or their representatives and analyst sit together and identify the features or something similar and set a tone for, or drive, the actual meeting, rather than everyone coming in directly and probably having a difficult discussion? 2. Bruce McCarthy says: 8 February 2008 at 12:48 am I have essentially the same issue. Buy-in is good but there are some people who tend to drag the discussion off on tangents and make group decision-making very difficult. Also, there are some decisions which should be owned by particular roles. I don t want to spend time discussing the doc writer s opinion on the visual design or the visual designer s opinion on the relative priority of features. The designer should own the visual design and the product owner should own the feature prioriti ation, no? 3. JObermark says: 22 March 2009 at 5:06 pm Perhaps in these cases where consensus is hard, it is most important to determine what decisions need to be made, and which do not. If there is no consensus, there is no decision, but maybe that means you wanted too firm a controlling hand on the group s activity, and the group is rebelling. Is there a smaller decision that will give enough direction without entailing the details that folks are filibustering or contending over? In other consensus-driven contexts I also like Starhawk s notion that some decisions cannot be made by deliberation because they are not concrete enough, and they should be made by oracle .

Agile promotes refactoring, so agree when you think you need the decision. If you cannot decide by then, make the decision arbitrarily. Then see if that nets you the data you needed to make the decision well to begin with. If so, refactor out the old decision and implement the new one. If not, the decision did not matter, your arbitrary choice was as good as any other. 4. nagaraja ramayya says: 16 November 2010 at 11:29 am i, This is in response to the comments by Bruce: The agile teams are(should be) made up of cross functional experts, people with multiple expertise, experienced and mature.Thus there is no single owner, the whole team owns every aspect.The whole team collaborates to deliver.team members should plan and develop their skill sets so that, everyone can own anything.That is when team is completely agile, else team is restricted by the skills of individuals and if an individual fall sick for a month, that sprint fails as apart from owner no one can complete his work. The other fall out is that each member is working on his own individual strand of work and is not really bothered about team's commitment as a whole , as he worries only about his deliveries ..thus team becomes a group of individuals and can not be called a 'team'. 5. Drill Sargeant! | Release Insights says: 18 February 2011 at 10:07 pm [...] core tenets of agile development is that the teams are intensely collaborative, self-managing, and empowered to achieve sprint goals. Management provides the strategic goals, infrastructure, and a [...]

A ile Principle 3: Time Waits For No Man!

by Kelly Waters, 11 March 2007 | 10 Key Principles of Agile Development

timescales are fixed.

In agile development, requirements evolve, but

This is in stark contrast to a traditional development project, where one of the earliest goals is to capture all known requirements and baseline the scope so that any other changes are subject to change control. Traditionally, users are educated that it s much more expensive to change or add requirements during or after the software is built. Some organisations quote some impressive statistics designed to frighten users into freezing the scope. The result It becomes imperative to include everything they can think of in fact everything they ever dreamed of! And what s more, it s all important for the first release, because we all know Phase 2 s are invariably hard to get approved once 80% of the benefits have been realised from Phase 1. Ironically, users may actually use only a tiny proportion of any software product, perhaps as low as 20% or less, yet many projects start life with a bloated scope. In part, this is because no-one is really sure at the outset which 20% of the product their users will actually use. Equally, even if the requirements are carefully analysed and prioritised, it is impossible to think of everything, things change, and things are understood differently by different people. Agile Development works on a completely different premise. Agile Development works on the premise that requirements emerge and evolve, and that however much analysis and design you do, this will always be the case because you cannot really know for sure what you want until you see and use the software. And in the time you would have spent analysing and reviewing requirements and designing a solution, external conditions could also have changed. So if you believe that point that no-one can really know what the right solution is at the outset when the requirements are written it s inherently difficult, perhaps even practically impossible, to build the right solution using a traditional approach to software development. Traditional projects fight change, with change control processes designed to minimise and resist change wherever possible. By contrast, Agile Development projects accept change; in fact they expect it. Because the only thing that s certain in life is change. There are different mechanisms in Agile Development to handle this reality. In Agile Development projects, requirements are allowed to evolve, but the timescale is fixed. So to include a new requirement, or to change a requirement, the user or product owner must remove a comparable amount of work from the project in order to accommodate the change. This ensures the team can remain focused on the agreed timescale, and allows the product to evolve into the right solution. It does, however, also pre -suppose that there s enough nonmandatory features included in the original timeframes to allow these trade-off decisions to occur without fundamentally compromising the end product. So what does the business expect from its development teams? Deliver the agreed business requirements, on time and within budget, and of course to an acceptable quality. All software development professionals will be well aware that you cannot realistically fix all of these factors and expect to meet expectations. Something must be variable in order for the project to succeed. In Agile Development, it is always the scope (or features of the product) that are variable, not the cost and timescale. Although the scope of an Agile Development project is variable, it is acknowledged that only a fraction of any product is really used by its users and therefore that not all features of a product are really essential. For this philosophy to work, it s imperative to start development

(dependencies permitting) with the core, highest priority features, making sure they are delivered in the earliest iterations. Unlike most traditional software development projects, the result is that the business has a fixed budget, based on the resources it can afford to invest in the project, and can make plans based on a launch date that is certain. Kelly. See also: 10 Key Principles of Agile Development

9 Responses to A ile Principle 3: Time Waits For No Man! 1. Dave Nicolette says: 13 March 2007 at 1:51 pm hich factors are fixed and which are variable depends on circumstances. In the general case, as you say, requirements evolve and timescales are fixed, but this is not always the case. Consider a project to migrate an existing application to a different platform, for whatever reason. There is no hard and fast date when the existing application will stop functioning. The requirements are fixed, since the goal of the project is to port the application s already-known functionality to a new platform. In that case, we don t have the option to drop features in order to meet a date, because the ported application must provide the same functionality as the existing one. But the existing application can remin in production as long as necessary. So we can change the delivery date, but we can t change the requirements. e could practice incremental delivery in this scenario, possibly, depending on circumstances. I think the key point about agile work is that we acknowledge it s not possible to lock in *all* factors simultaneously, as traditional management practices often demand. Some factors will vary anyway, even if we don t want them too, and it s better to recogni e that and control which factors can vary by intent than it is to wait for nature to take its course. 2. Kelly Waters says: 16 March 2007 at 8:49 am In my opinion, this scenario is no longer agile, i.e. the requirements are *fixed*. I would still advocate adopting many of the agile principles though, because you ll get partial advantage, and potentially big advantage, from the visibility it brings and the effect this has on your ability to manage risks and issues early while there s still time to react.

3.

Mike says: 24 March 2007 at 5:02 am e are currently involved in just such a project as dave described. e are trying to use agile methodology nevertheless. And keep in mind, just because on point or principle of agile does not apply in a particular case, that doesn t mean that the rest do not. This is not some sort of test of orthodoxy!

4.

Scott W, Ambler says: 28 March 2007 at 12:57 am There s the concept of an iron triangle in software development although the real name should probably be elastic triangle . The basic idea is that at least one of scope, cost, or schedule must vary otherwise quality suffers. Agilists insist on high quality, so we re not going to let that vary. Most agile teams will allow the scope (requirements) to vary but that doesn t always have to be the case. On some projects you do in fact have fixed requirements (granted, this is very rare). There s no reason why you can t still be agile in this situation. See http://www.ambysoft.com/essays /brokenTriangle.html for some thoughts on the triangle. - Scott

5.

Anonymous says: 30 March 2007 at 1:35 pm i, at the moment I am writing my master thesis about project management. In modern times almost all projects have become more complex and the future is uncertain as well. So I compare classical project management with agile methods. Can you give me reasons wh Agile Project y Management is discussed just in the field of software engineering? It must be possible to figure out requirements in other business fields as well ??? Greetings

6.

Kelly Waters says: 30 March 2007 at 4:23 pm i, Although the term agile seems to have been largely adopted for agile software development, the principles can certainly be applied outside software development projects where there s an

apetite for it. In fact the Scrum agile management practice was born out of studies of Toyota s lean manufacturing, which you might want to read up on. Kelly. 7. Diver232 says: 12 June 2007 at 9:50 am I always draw up a MOSCO list of requirements with the users. Must have not negotiable, this will happen Should have if we have the time Could have nice idea, maybe next release huh? ont have who wanted this? Timescale is fixed, but you regularly review the contents of the lists with the users 8. Federico Grilli says: 10 January 2008 at 9:14 am Because the only thing that s certain in life is change. ow true. Next time we could reinforce this concept and impress stakeholders and friends by quoting Plato who understood this two thousand and four-hundred years ago: Everything is becoming. Nothing is. Actually, according to Plato, this is true only of wordly, material things, those we get to know through our senses. owever, they are but shallow, unperfect copies of the Idea Forms l which are timeless, perfect and immutable (kind of java.lang.String) and which we get to know through our mind. But, for the sake of our agile projects, I would not say this to the customers. :) 9. JObermark says: 22 March 2009 at 5:56 pm Agilists seem to come primarily from consulting backgrounds where folks actually think projects have boundaries. In most of our industry, this is an illusion, a group oversees maintenance of a few different products over unforeseeably long timescales. Chopping life up into projects is lying: it lets folks bury the cost of maintenance. So in the normal case where a product outlives all projects, it is easier to hew to the line that cost and time are fixed. There are n employees, and they work 40-hour weeks (until the next recession, when there are n-7 ) Reduced quality just reduces future scope, as a certain percentage of the time before the next release will be lost to friction. Only scope can ever really change, and even that is scope *as of the next release cycle*. I think it would be wise of methodologists to take this seriously, and adjust their norms to the norm. Especially agile thinkers should, because I really think this style of development is better for the long run than for a succession of short runs.

Agile Principle 4: Agile Requirements Are Barely Sufficient

by Kelly Waters, 17 March 2007 | 10 Key Principles of Agile Development

Agile development teams capture requirements at a high level and on a piecemeal basis, just-intime for each feature to be developed. Agile requirements are ideally visual and should be barely sufficient, i.e. the absolute minimum required to enable development and testing to proceed with reasonable efficiency. The rationale for this is to minimise the time spent on anything that doesn t actually form part of the end product. Agile Development can be mistaken by some as meaning there s no process; you just make things up as you go along in other words, JFDI! That approach is not so much Agile but Fragile Although Agile Development is much more flexible than more traditional development methodologies, Agile Development does nevertheless have quite a bit of rigour and is based on the fairly structured approach of lean manufacturing as pioneered by Toyota. I personally believe Agile Development teams can build better products if they have a reasonably clear idea of the overall requirements before setting out on development, so that incorrect design decisions don t lead the team down dead ends and also so a sensible investment case can be made to get the project funded. However any requirements captured at the outset should be captured at a high level and in a visual format, perhaps for example as a storyboard of the user interface. At this stage, requirements should be understood enough to determine the outline scope of the product and produce high level budgetary estimates and no more. Ideally, Agile Development teams capture these high level requirements in workshops, working together in a highly collaborative way so that all team members understand the requirements as well as each other. It is not necessarily the remit of one person, like the Business Analyst in more traditional projects, to gather the requirements independently and write them all down; it s a joint activity of the team that allows everyone to contribute, challenge and understand what s needed. And just as importantly, why.

XP (eXtreme Programming) breaks requirements down into small bite-size pieces called User Stories. These are fundamentally similar to Use Cases but are lightweight and more simplistic in their nature. An Agile Development team (including a key user or product owner from the business) visualises requirements in whiteboarding sessions and creates storyboards (sequences of screen shots, visuals, sketches or wireframes) to show roughly how the solution will look and how the user s interaction will flow in the solution. There is no lengthy requirements document or specification unless there is an area of complexity that really warrants it. Otherwise the storyboards are just annotated and only where necessary. A common approach amongst Agile Development teams is to represent each requirement, use case or user story, on a card and use a T-card system to allow stories to be moved around easily as the user/business representative on the project adjusts priorities. Requirements are broken down into very small pieces in order to achieve this; and actually the fact it s going on a card forces it to be broken down small. The advantage this has over lengthy documentation is that it s extremely visual and tangible; you can stand around the T-card system and whiteboard discussing progress, issues and priorities. The timeframe of an agile development project is fixed, whereas the features are variable. Should it be necessary to change priority or add new requirements into the project, the user/business representative physically has to remove a comparable amount of work from scope before they can place the new card into the project. This is a big contrast to a common situation where the business owner sends numerous new and changed requirements by email and/or verbally, somehow expecting the new and existing features to still be delivered in the original timeframes. Traditional project teams that don t control changes can end up with the dreaded scope creep, one of the most common reasons for software development projects to fail. Agile teams, by contrast, accept change; in fact they expect it. But they manage change by fixing the timescales and trading-off features. Cards can of course be backed up by documentation as appropriate, but always the principle of agile development is to document the bare minimum amount of information that will allow a feature to be developed, and always broken down into very small units. Using the Scrum agile management practice, requirements (or features or stories, whatever language you prefer to use) are broken down into tasks of no more than 16 hours (i.e. 2 working days) and preferably no more than 8 hours, so progress can be measured objectively on a daily basis. One thing I think should certainly be adopted from PRINCE2, the very non -agile project management methodology, is the idea of making sure all items are deliverables rather than activities or tasks. You can see a deliverable and kick the tyres , in order to judge its quality and completeness. A task you cannot. Kelly.

See also: 10 Key Principles of Agile Development hat are User Stories riting Good User Stories

13 Responses to A ile Principle 4: A ile Requirements Are Barel Su icient 1. Scott W, Ambler says: 28 March 2007 at 1:02 am ith Agile Model Driven Development (AMDD), see http://www.agilemodeling.com /essays/amdd.htm , we suggest that you do a little bit of high-level modeling up front as Kelly suggests. To get the details you model storm on a just-in-time basis, thus ensuring that you only invest time in modeling the requirements that you re actually going to implement. In short, the advice that Kelly provides is pretty much dead on to what the AM community has been promoting for the past six years. - Scott 2. no snake oil for me please says: 1 April 2007 at 5:25 pm This looks like another step around the circle. Pretty soon, we will be back where we started with non-agile development. Let s look at the well-used analogy of building a large office building. Obviously there is quite a bit of planning that has to be done before you start construction. In fact, if you look at most projects in the real world, they work the same way. It is only with so-called agile development that we think we can get something for free. But it is a lie. For even if you have everyone on your team that can build skyscrapers in their sleep, T IS PROJECT is not the same as the last project. It means a lot of planning and communicating has to be done to get all the experts on the same page for the current project. You don t get to write a few stories and then just jump in your heavy machinery and build the building. Unless you want to build something horrible. In many ways, agile development is about ultimate job security. There are no real requirements, no real specifications, nothing except some ad-hoc workflows amongst a specific group of individuals. If you want bug fixes or a new version, you are beholden to your agile developers.



Maybe it should have been called crafty development . A little honesty wouldn t hurt, would it? 3. Kelly Waters says: 1 April 2007 at 8:09 pm Reply to no snake oil for me please Not sure if you actually read my post? I certainly didn t advocate jumping straight in. I was advocating high-level visual requirements at the outset, and defining requirements on a just-intime basis per feature rather than all up-front. Unlike a building, software can evolve Kelly. 4. Anonymous says: 20 July 2007 at 4:31 pm response to no snake oil . It s people like you, who think that developing software is like developing a building, that lead us to using the waterfall method. The reality is that developing software is nothing like developing a building. The waterfall approach is, and always has been, a square peg in a round hole. As for ultimate job security taking 12 months to finish a project that can be completed in 6 by over analyzing and over documenting sounds like ultimate job security to me. 5. Josh Milane says: 23 August 2007 at 5:09 pm RIP (Rapid Iterative Prototyping) uses visual guideposts along the way as well and may be Agile but I am becoming more and more convinced that Agile is a catchphrase more than a discipline. 6. Kelly Waters says: 24 August 2007 at 6:55 am Yes, you re right. Agile is not a discipline. It s a philosophy. A set of principles and values. A broad approach. Like all things in life, as this broad philosophy exists, it needs a name. It needs a name so we can differentiate the approach from the more traditional (waterfall) approach to development, i.e. analyse, develop, test, etc.

If you want to call that name a catchphrase that s fine, but the term seems to undermine the fact that there is such a thing as an Agile philosophy. Agile *disciplines* are those methodologies that materially support these philosophies, principles and values. For instance Scrum, XP and DSDM, etc. Agile in itself is not a discpline. 7. Kevin says: 11 September 2007 at 1:49 pm Although I see tremendous value in close amongst team members in developing software, I wonder how the Agile Methodology allows for the passing the knowledge of how the system works without the documentation in specifications. My reservations about the Agile Method is that someone has to go back later and figure out what was done two or three years back to make feature a work the way it does. ithout documentation a systems analyst has to spend more time to figure out how feature works. I am sure others who work in an IT shop will find this true. e don t develop software for a large potential consumer audience, we develop software that needs to be used by itnernal users as well as an existing client base. 8. ananth says: 5 November 2007 at 9:30 pm You are 100% right! Currently I am trying to read thru the functionality and come up with a AS IS document that can be ratified by the Business User, as the current IT group take the AGILE very convenitently to code and forget the document part!! Pathetic!! 9. Kelly Waters says: 6 November 2007 at 8:07 am A couple of points Firstly, I have worked on may waterfall projects where the spec is barely a good reflection of the finished system by the end of the project, and where commercial constraints prevent us from having the time to go back and update it all. In this case, having a document that is believed to be true and accurate is potentially dangerous and misleading. As a consequence developers learn not to rely on it and base their decisions on the code anyway. I do accept, however, that the documentation can provide some useful context, as long as it s not taken as gospel. Secondly, the above comment is yet another comment that suggests you didn t really read my post and that you d formed your own view before you read it. I stated that requirements *are* captured. It s just that they re lightweight and visual, e.g. wireframes/storyboards, at the outset, and details are captured per feature as you go. hy couldn t these feature documents/use cases/user stories, (or whatever you re using) be kept together and provide the same context as you d have got if you d written it all up front? The only difference is, writing them as they are needed and not all at the beginning many months before they are developed, they re more likely to be in line with the finished software.

Kelly. 10. pkr says: 4 January 2008 at 6:21 pm re: no specifications the idea is that you end up with executable specifications . Ideally these are still written in such a way that the majority of stakeholders will understand them. Executable specs have the advantage that the product cannot work without changes to them (assuming you write them in the first place) whereas a word doc gathering dust somewhere may no longer represent what *is* happening. For examples see http://www.concordion.org/ FIT/Fitnesse and API documenting such as Sandcastle 11. Eddie says: 18 November 2008 at 9:02 pm There are trade-offs for each approach, and I have in the past debated the defense of each approach. The ultimate factor in determining how well each approach applies is the acceptance of the company for which you are developing software, and the committme from that company nt to adhere to one approach or the other. If you are in complete control, then this discussion would be invalidated. There are companies who take comfort in waterfall because everything is explicitly measurable, and contracts are in place that provide an explicit agreement for the deliverables. Other companies who have trusting entities, good relationships and follow the same mantra of the best possible software in the best possible time and are not under the pressures that waterfall traditionally brings to the table are more accepting of the unknown(s) and are usually more in favor of the ability to change directions more quickly. Unless you are working for the government (DOE, DOD), etc., I have yet to see a development shop where waterfall or agile are followed in such a rigid manor that you end up with executable specifications or the agile requisite of change on a dime. Ultimately the tolerances of the company will decide the process. 12. JObermark says: 22 March 2009 at 6:25 pm Even when the requirements are written up front, people still write user manuals. So why do both? hat we need is an agile methodology that allows for T E ENTIRE PRODUCT, and that includes the user-training material, to be delivered on schedule. Then folks cannot complain later that functionality is not documented. I think this precludes an old-fashioned user manual, and requires creative people in the documentation community to come on board. e need to think through some kind of knowledge web that can capture the changing requirements at a user level and still be right at the end.

13.

A_flj_ says: 21 August 2009 at 12:50 pm I agree with no snake oil with one important difference: what programmers build are the skyscraper's blueprints. The compiler is the one building the skyscraper. That being said: blueprints can evolve. owever, once the compiler or the builders set them in stone, the acutal installed program/skyscraper cannot change anymore (unless rebuilt/reinstalled). hat we are arguing about is a methodology to make the blueprints. Car manufacturers make many sets of prototypes and blueprints before they get to the final version. Archtiects and civil engineers less so they test each piece individually. But kitchen appliances makers do little of either. They may make a few models, but for them it is essentially a talented industrial designer designing something smart. IMO, it's more or less the same with software. It all depends on what precisely we are doing. Now, there are only very few skyscrapers designed each year, when compared to car models, and even car models there are few a year, when compared for instance with coffee makers a coffee maker being one of the more complicated kitchen appliances. hile the skyscraper designers may need an agile process, because the costs caused by them iterating several times over the whole design are neglectable when comparted to the benefits the skyscraper will bring in, somebody designing and building a custom kitchen furniture for a new house will probably not get financing for doing the design ten times over, with three prototypes thrown in between. Therefore, agile is less of a choice there. Besides, there are highly skilled architects and civil engineers working at the plans for the skyscraper, and possibly just a carpenter working by the advice of an interior designer furnishing the kitchen, so probably there won't be the skills in place to try out several variants, besides the customers not wanting to pay for morethan just the minimum cost required to get the job done. Nevertheless, all that agile methods advocates talk about are skyscraper plans. hich is OK, as long as they don't try to get me buy into agile methods while I'm doing my custom intranet database interfaces for paying customers.

A ile Principle 5: How Do You Eat An Elep ant?

by Kelly Waters, 25 March 2007 | 10 Key Principles of Agile Development

How do you eat an elephant? One bite at a time! Likewise, agile development projects are delivered in small bite-sized pieces, delivering small, incremental *releases* and iterating. In more traditional software development projects, the (simplified) lifecycle is Analyse, Develop, Test first gathering all known requirements for the whole product, then developing all elements of the software, then testing that the entire product is fit for release. In agile software development, the cycle is Analyse, Develop, Test; Analyse, Develop, Test; and so on doing each step for each feature, one feature at a time. Advantages of this iterative approach to software development include
y y y y

Reduced risk: clear visibility of what s completed to date throughout a project Increased value: delivering some benefits early; being able to release the product whenever it s deemed good enough, rather than having to wait for all intended features to be ready More flexibility/agility: can choose to change direction or adapt the next iterations based on actually seeing and using the software Better cost management: if, like all-too-many software development projects, you run over budget, some value can still be realised; you don t have to scrap the whole thing if you run short of funds For this approach to be practical, each feature must be fully developed, to the extent that it s ready to be shipped, before moving on. Another practicality is to make sure features are developed in *priority* order, not necessarily in a logical order by function. Otherwise you could run out of time, having built some of the l ess important features as in agile software development, the timescales are fixed. Building the features of the software broad but shallow is also advisable for the same reason. Only when you ve completed all your must -have features, move on to the should-haves, and only then move on to the could-haves. Otherwise you can get into a situation where your earlier features are functionally rich, whereas later features of the software are increasingly less sophisticated as time runs out. Try to keep your product backlog or feature list expressed in terms of use cases, user stories, or features not technical tasks. Ideally each item on the list should always be something of value

to the user, and always deliverables rather than activities so you can kick the tyres and judge their completeness, quality and readiness for release. These are important characteristics of iterative, feature-driven development and they re essential if you plan to deliver in fixed timescales one of the 10 key principles of agile software development. Kelly. 6 Responses to A ile Principle 5: How Do You Eat An Elep ant? 1. Mike says: 26 March 2007 at 5:34 pm i Kelly. I posted a link from my blog to yours. Thanks for the information. 2. Anonymous says: 5 July 2007 at 2:14 am Very nice and succinct. I will borrow some language for a presentation I need to give! Thanks. 3. srutanjay says: 14 May 2008 at 9:03 am ell, when changes happen over a small discussion or verbally it is important that those are tracked. how are the changes documented. At the end of the day it is important to track the requirements, though it may keep changing. Thanks. 4. Kelly Waters says: 14 May 2008 at 4:42 pm i srutanjay You say it s important to track the requirements Kelly. 5. srutanjay says: 15 May 2008 at 9:39 am why is that?

Hi kelly, First, when requirements keep getting modified due to iterative method of development, one may need to see how the final requirement has shaped up as compared to the initial one. Secondly, as time and cost are fixed, some of the requirements may be differred for a later release. Thanks. 6. Kelly Waters says: 15 May 2008 at 10:32 am Hi srutanjay Re your first point, I have worked in development for many years and the only reason I ve ever had to do this is to argue with people about why we re late. In agile development, the key stakeholders (especially the product owner) should have been involved throughout, so this risk is mitigated. In my experience of agile, I don t think I ve seen this need once as a result. If any requirements are defered for a later release, they can simply be captured on the product backlog and a new user story written nearer the time of development. It s a very interesting point though. Has anyone else got a view on this? Kelly.

A ile Principle 6: Fast But Not So Furious

by Kelly Waters, 31 March 2007 | 10 Key Principles of Agile Development

Agile development is all about frequent delivery of products. In a truly agile world, gone are the days of the 12 month project. In an agile world, a 3-6 month project is strategic!

Nowhere is this more true than on the web. The web is a fast moving place. And with the luxury of centrally hosted solutions, there s every opportuni ty to break what would have traditionally been a project into a list of features, and deliver incrementally on a very regular basis ideally even feature by feature. On the web, it s increasingly accepted for products to be released early (when they re basic, not when they re faulty!). Particularly in the Web 2.0 world, it s a kind of perpetual beta. In this situation, why wouldn t you want to derive some benefits early? Why wouldn t you want to hear real user/customer feedback before you build everything ? Why wouldn t you want to look at your web metrics and see what works, and what doesn t, before building everything ? And this is only really possible due to some of the other important principles of agile development. The iterative approach, requirements being lightweight and captured just-in-time, being feature-driven, testing integrated throughout the lifecycle, and so on. So how frequent is *frequent*? Scrum says break things into 30 day Sprints. That s certainly frequent compared to most traditional software development projects. Consider a major back-office system in a large corporation, with traditional projects of 6-12 months+, and all the implications of a big rollout and potentially training to hundreds of users. 30 days is a bit too frequent I think. The overhead of releasing the sof tware is just too large to be practical on such a regular basis. But consider a web site, a web-based product or even more dynamic something like my blog. There s no rollout overhead it s an automated central deployment to all users, and for the blog it s a single click. No-one s paying for the service. If something s wrong, no-one dies. And it can be rolled back as quickly as it s deployed. There may be thousands of users, even millions of users of a web site every month. But none of them need to be trained. And you can evaluate the impact on the user experience, and the user s behaviour, through metrics within 2 hours and on an ongoing basis. In that scenario, 30 days is a lifetime! Competitors won t wait. Speed-to-market is a significant competitive edge. The value of firstmover advantage is potentially enormous. Whilst it s not always the case, research shows that those first to market 80% of the time win; and end up clear market leaders. So how frequent is *frequent enough*? Think carefully about your own situation. Think about the two extremes I ve described above. Think about what s right for you; your organisation; your product; your market; your customers. Think about what s right for *you*, in your *particular situation*. There is no right or w rong answer. Only what works for you, and what doesn t. What is fairly important is to make this a positive decision to decide what s appropriate for you. And then to stick, if you can, to a regular release cycle. A regular release cycle allows you to plan . It allows your infrastructure and ops teams to plan. It allows your business colleagues to plan. It allows your launch events, marketing campaigns, etc to be planned. And because agile development works to a fixed timescale, these plans are assured.

A regular release cycle also allows you to learn more effectively. Your estimating might be good, it might be bad. Hopefully it s at least consistent. If you estimate features at a granular level (ideally less than 1 day) and track your velocity (how much of your estimate you actually delivered in each Sprint), in time you ll begin to understand your *normal* delivery rate. And when you understand this well, you ll be surprised how predictable you can be. And let s face it, managing expectations is really all about predictability. If people know what to expect, they re generally happy. If they don t, they re not happy. Maybe even furious! So, in agile development, focus on frequent delivery of products. And perhaps even more importantly, focus on consistent delivery of products. Kelly.

3 Responses to A ile Principle 6: Fast But Not So Furious 1. Derek Morrison says: 3 April 2007 at 1:50 pm I think the constant delivery makes good business sense the ability for all stakeholders: sales, marketing etc to plan ahead and synchronise their plans with technical delivery of features/projects also makes good sense. I have posted an article on my blog a few days ago that discusses good business sense and tec nical sense coming together to make . Derek: All About Product Management 2. Mishkin Berteig says: 14 April 2007 at 9:27 pm In my experience, which covers everything from large $100M+ projects to tiny projects, 30 calendar days is the absolute maximum Sprint or iteration length. Most organizations settle into a comfortable length of 10 working days. Letting your Sprint length be too long just leaves all sorts of problems uncovered. The shorter the sprint length, the faster you learn to do short sprints! 3. Michael James says: 16 April 2007 at 2:28 am One thing you might have missed here is the distinction between Sprint and Release. Scrum doesn t require a release every Sprint, just a demonstration of potentially shippable product increment. Potentially shippable means we could bring it into shippable form after one stabilization sprint.

As Mishkin wrote, I d never go over a 30 -day Sprint. mj

Agile Principle 7: Done Means DONE!

by Kelly Waters, 8 April 2007 | 10 Key Principles of Agile Development

In agile development, done should really mean DONE! . Features developed within an iteration (Sprint in Scrum), should be 100% complete by the end of the Sprint. Too often in software development, done doesn t really mean DONE! . It doesn t mean tested. It doesn t necessarily mean styled. And it certainly doesn t usually mean accepted by the product owner. It just means developed. In an ideal situation, each iteration or Sprint should lead to a release of the product. Certainly that s the case on BAU (Business As Usual) changes to existing products. On projects it s not feasible to do a release after every Sprint, however completing each feature in turn enables a very precise view of progress and how far complete the overall project really is or isn t. So, in agile development, make sure that each feature is fully developed, tested, styled, and accepted by the product owner before counting it as DONE! . And if there s any doubt about what activities should or shouldn t be completed within the Sprint for each feature, DONE! should mean shippable. The feature may rely on other features being completed before the product could really be shipped. But the feature on its own merit should be shippable. So if you re ever unsure if a feature is done enough , ask one simple question Is this feature ready to be shipped? . It s also important to really complete each feature before moving on to the next Of course multiple features can be developed in parallel in a team situation. But within the work of each developer, do not move on to a new feature until the last one is shippable. This is

important to ensure the overall product is in a shippable state at the end of the Sprint, not in a state where multiple features are 90% complete or untested, as is more usual in traditional development projects. In agile development, done really should mean DONE! . Kelly. See also: 10 Key Principles of Agile Software Development Time waits for no man! How d you eat an elephant? Fast but not so furious!

12 Responses to Agile Principle 7: Done Means D NE! 1. Jonah Dempcy says: 8 April 2007 at 9:24 pm I agree entirely. One way I have heard it compared is to say, there is done and then there is done done done. The difference is that the former might be when you feel that you are finished working on it, but done done done means it has been reviewed (both design review and code review), it has been tested (by yourself and hopefully a QA team) and it is ready to release in every possible sense of the term. 2. Kris says: 8 April 2007 at 11:32 pm I certainly agree with your posting, but as I posted on here, I see a large problem getting some features to shippable in a short amount of time. If you have 1 user story that takes the team 2 sprints to complete you surely can t be done at the end of 1 sprint. And if the feature isn t shippable till say 5 user stories are complete then you may be able to only get to 2 of them per sprint, and you wouldn t be shippable till sprint 3. I d be interested on your thoughts. 3. Kelly Waters says: 9 April 2007 at 5:04 pm First of all, you can cheat a bit :-) In my mind, a user story equals a feature, so in the case where there are 5 user stories, treat as 5 features.

"

If the product isn t shippable until all 5 features are complete, because it doesn t really make sense piecemeal, that s fine. It s the feature that has to be shippable quality; not necessarily that it would be appropriate to ship the product after every feature. But, when you say a feature is complete, it must really be shippable once the dependent features are also complete. ith features broken down into their smallest possible pieces, if you still have 1 feature that spans 2 sprints, you should seriously consider whether your sprints are too short for your situation. Your product, tools, team size, skills, features, etc, etc determine what is an optimum sprint length for *you* Hope this helps Kelly. 4. Kelly Waters says: 9 April 2007 at 5:09 pm If you want to discuss this issue or others with your peers, why not give the forum a try http://www.groups.google.com/group/allaboutagile 5. Anonymous says: 10 April 2007 at 9:21 pm Fine for software development, but I think Google and 37 signals would differ on this, it needs to be still bug free and done, but not 100% done, if Google kept Gmail in secret until its out of beta it wouldn t be as much of a success. 6. Kelly Waters says: 14 April 2007 at 7:13 am I agree. You don t have to develop all the intended features. You don t even have to make the features as functionally rich as you intend to. But you do need to make sure that the features developed in *each* Sprint/iteration are DONE! , including testing, styling, user acceptance, etc. 7. Peter's mommy says: 28 October 2007 at 11:30 am

Our problem is the developers lacking experience out in the field doesn t really understand the effect of what they conceive as a minor problem or glitch. hile other developers dive into details. tiny details. 8. pkr says: 8 January 2008 at 5:33 am I agree that there is a need to make done mean that it has completed its analyse to test cycle but I don t think it means the feature is done. I like the idea of scale (see Jeff Patton) where a feature can be split into separate deliverable independently useful parts. I.e. you can deliver the essentials of a feature in incr n so that you could consider it usable. However, you still intend to improve it in incr n+1. (I don t believe that these are typically new stories). 9. Anonymous says: 10 January 2008 at 5:43 pm hat happens when you complete your stories near the end of the iteration and it will take QA several days to verify the story is complete and working? In the meantime you are planning for the next iteration and have no idea if you really are complete, until QA catch up all the time? 10. KMK says: 9 August 2008 at 5:48 am I have exactly the same scenario in my team(As mentioned by anonymous reader above). Currently, we moved testing to next sprint. But what if the testing team finds out a lots of bugs by the end of testing? Shud the bug fixing be moved to another sprint? Overall extending it to 3 sprints!! 11. Anonymous says: 29 August 2008 at 10:40 pm You shouldn t leave several days of testing until the end of the iteration. The testing for each task/deliverable within an iteration should be done as soon as possible (start testing on the first day if you can). As you approach the end of your iteration, you should already have everything tested and all bugs fixed. 12. Jan says: 21 October 2009 at 11:56 am I'm very interested in your point "complete each feature before moving on to the next ".

We are building a shared agile development team, that is we have multiple projects with multiple project owners. I can imagine situation that the team completes an underestimated feature. This causes another feature to be shifted into the next iteration. This is ok when this is in same project. But what to do when this affects another project in the iteration? That means finishing of a task in ProjectA becomes longer and there is no time for start the work on a task in ProjectB. How can I advocate this situation for ProjectB owner. By the way I found only one article about How To Share An Agile Development Team. Do you know any other sources?

Agile Principle 8: Enough Is Enough!

by Kelly Waters, 15 April 2007 | 10 Key Principles of Agile Development

Pareto s law is more commonly known as the 80/20 rule. The theory is about the law of distribution and how many things have a similar distribution curve. This means that * typically* 80% of your results may actually come from only 20% of your efforts! Pareto s law can be seen in many situations not literally 80/20 but certainly the principle that the majority of your results will often come from the minority of your efforts. So the really smart people are the people who can see (up-front without the benefit of hindsight) *which* 20% to focus on. In agile development, we should try to apply the 80/20 rule, seeking to focus on the important 20% of effort that gets the majority of the results. If the quality of your application isn t life -threatening, if you have control over the scope, and if speed-to-market is of primary importance, why not seek to deliver the important 80% of your product in just 20% of the time? In fact, in that particular scenario, you could ask why you would ever bother doing the last 20%?

Now that doesn t mean your product should be fundamentally flawed, a bad user experience, or full of faults. It just means that developing some features, or the richness of some features, is going the extra mile and has a diminishing return that may not be worthwhile. So does that statement conflict with my other recent post done means DONE! ? Not really. Because within each Sprint or iteration, what you *do* choose to develop *does* need to be 100% complete within the iteration. As a slight aside, I was at Microsoft last week for an executive briefing on all their latest products. Sharepoint 2007 looks great by the way; a real leap from the earlier versions which were not really up to scratch. Vista, for those that haven t tried it, looked rather slow even on a laptop with GB RAM! And apart from being slightly prettier didn t really seem to offer much. Windows Workflow Services and .Net v3 looked pretty cool, if you can afford to develop in Microsoft tools ;-) Anyway, back to my point about the 80/20 rule, Microsoft s own research found that the average user of Word uses only *8%* of the functionality. That s 8%! And I wouldn t mind betting at least 80% of us use the same 8% too! [ assertion]. If Microsoft had developed only the important 8% of Word, maybe they could still have captured the same market share? Maybe, maybe not; sadly we will never know. It s also worth considering the impact on user experience. Google has shown us that users often prefer apps that do just what you want. That s *just* what you want. And no more. The rest is arguably clutter and actually interferes with the user experience for only a limited benefit to a limited set of users. So in an agile development world, when you re developing a brand new product, t hink very hard about what your app is *really* all about. Could you take it to market with all the important features, or with features that are less functionally rich, in a fraction of the time? Apart from reduced cost, reduced risk and higher benefits by being quicker to market, you also get to build on the first release of the product based on real customer feedback. So all of this is really common sense I suppose. But it s amazing how often development teams, with all the right intentions, over-engineer their solution. Either technically, or functionally, or both. The really tough question, however, is can you see up -front *which* 20% is the important 20%? the 20% that will deliver 80% of the results. In very many cases, the answer sadly is no. Kelly. For more agile principles, see 10 Key Principles of Agile Software Development

9 Responses to Agile Principle 8: Enough Is Enough! 1. Siobhan says: 2 May 2007 at 7:02 pm The 80/20 rule is one often applied in leadership and management development and is therefore likely to be a concept that can be rolled out to customers in a manner in which they feel confident. It is also interesting to consider the useability of developed software from a user perspective if I am never going to use a specific piece of functionality then it s requirement is questionable. In cases where software is designed in a manner that will allow increased or even altered functionality in the future, ensuring that users are enthusiastic and comfortable with common tasks during early iterations builds trust and confidence in the development. This often results in increased user participation, better feedback and ultimatley and cleaner and better solution. So all in all, I agree, the Pareto principle can be a powerful tool for organising iterations, and also communicating those to the client and end user. 2. Damon Poole says: 13 May 2007 at 3:52 am Great post! I suggest that you don t have to know up front what that 20% is right out of the gate. Even if you just guess what it is, that s probably good enough. Once you have that 20% to show, you ll get the user feedback that will help you make an even better guess in the next release. Plus, if you can t guess what that 20% is, perhaps you are in the wrong market or need to spend more time learning about your market! 3. Anonymous says: 23 July 2007 at 10:06 pm ell, it seems to me that one could know 80% of the 80% that needs to be done up front, by doing 20% of the research you d have to do to get the other 20%. And so on . 4. Anonymous says: 29 April 2008 at 3:52 pm

This is a fine concept on paper, yet I rarely find real world examples in which demonstrate HO you save 80% of the time. In every project I ve worked on (software project that is), it s not the case that 80% of the requested features can easily be split out and delivered in short order. The 80/20 rule actually ends up meaning 80% of the code is easy to write, given a reasonable architectural and design pass was done. But there is the final 20%, required in order to get the application to actually boot, run, stay running, and have a modicum of performance . This has always been the case regardless of how much I minimize scope to get things out the door faster. 80% bang for 20% effort does NOT logically imply that you can get away with not doing the 20%, unless you are writing vapor ware, proof of concepts, or college projects. 5. Pedro says: 14 August 2008 at 3:15 am ell, maybe you are just using the principle with the wrong fact. I mean, why not develop 20 % of the features that add 80 % of the software value. This approach can be hold on what Poppendieck reports on their Lean Software Development . They say that a Standish Group study found that 45% of software features are never used and 19% are rarely used. So, 64% of the features you implemented in the software does not aggregate no value to the product. SO, how many that could you have saved focusing on what really adds value to the product. 6. Anonymous says: 9 September 2008 at 9:09 am ell, and I always thought that implementing 90% of the features take up 90% of the time and the other 10% require the other 90% of the time. I guess I should try out this agile thing, if that brings that down to 80% :-) (Thanks for the nice article, btw. :-) 7. JObermark says: 24 March 2009 at 12:12 am As a mathematician, I feel obligated to point out that almost everyone misunderstands the nature of statistical laws. Awareness of the truth of an inescapable trend does not mean you can escape the trend! You will still most likely spend 80% of your effort on what you consider to be only 20% of the difficulty, even if you keep trying to avoid the perceived over-concentration of effort. Therefore avoiding unwanted features has nothing to do with the real, original 80/20 rule. Neither does the idea of rapid rollout and later stabilization. There is no 80% of the work that can be saved or reallocated by finding some pernicious 20% of the problem space that way lie the dragons of analysis paralysis and heavy protocol.

Pareto s is a law of a statistical nature, not an observation of human decision-making processes. So we need to work with the truth instead of against it. As work draws time and its requirements just won t settle down, don t resent it or take it personally. The perceived disparity of returns is preordained, and will average out to 4-to-1, whatever you do. (And that is lovely, because it is true. Plato s God says so.) So detach from it. Do not be led to consider unexpectedly hard work more important, or less. Do not give it more scrutiny and criticism, or less. Do not declare war on it or dig in to discover the cause of this perversity. Doing so is exactly the kind of reflexive over-analysis to which agile technologies are meant to be an anodyne. 8. Alena Shechkova says: 1 December 2009 at 9:12 am Thanks for the fantastic article! The Pareto's principle should be undoubtedly taken into consideration when developing software, because we are catering for the end user in fact. It would be great if all the clients understood it. 9. Anonymous says: 4 May 2010 at 10:40 am I only read 20% of the article. I guess I got 80% of the content that way.

Agile Principle 9: Agile Testing Is Not For Dummies!

by Kelly Waters, 22 April 2007 | 10 Key Principles of Agile Development

In agile development, testing is integrated throughout the lifecycle; testing the software continuously throughout its development.

Agile development does not have a separate test phase as such. Developers are much more heavily engaged in testing, writing automated repeatable unit tests to validate their code. Apart from being geared towards better quality software, this is also important to support the principle of small, iterative, incremental releases. With automated repeatable unit tests, testing can be done as part of the build, ensuring that all features are working correctly each time the build is produced. And builds should be regular, at least daily, so integration is done as you go too. The purpose of these principles is to keep the software in releasable condition throughout the development, so it can be shipped whenever it s appropriate. The XP (Extreme Programming) agile methodology goes further still. XP recommends test driven development, writing tests before writing the software. But testing shouldn t only be done by developers throu ghout the development. There is still a very important role for professional testers, as we all know developers can t test for toffee! ) The role of a tester can change considerably in agile development, into a role more akin to quality assurance than purely testing. There are considerable advantages having testers involved from the outset. This is compounded further by the lightweight approach to requirements in agile development, and the emphasis on conversation and collaboration to clarify requirements more than the traditional approach of specifications and documentation. Although requirements can be clarified in some detail in agile development (as long as they are done just-in-time and not all up-front), it is quite possible for this to result in some ambiguity and/or some cases where not all team members have the same understanding of the requirements. So what does this mean for an agile tester? A common concern from testers moving to an agile development approach particularly from those moving from a much more formal environment is that they don t know precisely what they re testing for. They don t have a detailed spec to test against, so how can they possibly test it? Even in a more traditional development environment, I always argued that testers could test that software meets a spec, and yet the product could still be poor quality, maybe because the requirement was poorly specified or because it was clearly written but just not a very good idea in the first place! A spec does not necessarily make the product good! In agile development, there s a belief that sometimes maybe even often these things are only really evident when the software can be seen running. By delivering small incremental releases and by measuring progress only by working software, the acid test is seeing the software and only then can you really judge for sure whether or not it s good quality. Agile testing therefore calls for more judgement from a tester, the application of more expertise about what s good and what s not, the ability to be more flexible and having the conf idence to work more from your own knowledge of what good looks like. It s certainly not just a case of following a test script, making sure the software does what it says in the spec.

And for these reasons, agile testing is not for dummies! Kelly. For further reading about agile principles, see 10 Key Principles of Agile Software Development.

6. Responses to Agile Principle 9: Agile Testing Is Not For Dummies! 1. Piersj says: 27 April 2007 at 11:59 am I came across this netcase on agile testing which might be of interest? http://parlezuml.com/blog/?postid=394 2. Paul Littlebury says: 30 June 2007 at 2:00 pm Agile a good methodology, but hardly re-invents any testing rules. Testing should always be involved from the outset, any software development manual from 1980s onwards will say that. Developers seem to have forgotten their own training. Modern software development happens in tighter more rapid cycles its that simple. hat is generally missed out from Agile, which is the the whole point is involvement by the client, or the end-user is no such client exists. Making software quickly is not the focus of Agile, it s retaining control and ensuring that what a client wants is what they get, and that changes can be made mid-stream with minimal impact. Have a look at usabilitymustdie.com, as it contains some good reality -checks for developers. Not Agile specific, but succinctly summarises to crisis in modern development. Development has become far too smug and self-congratulatory to the point of dictating to users what they want, instead of LISTENING. 3. Steve Watson says: 19 July 2007 at 9:58 am I must admit that after 18 years in a waterfall approach, it would be astruggle to change to an Agile approach. However I can see the benefits of throwing off the shackles that bind us as testers and starting to have more impact on what is produced. e have come a long way from throwing code at testers at the end of the dev cycle, and testers only being used to match results versus spec. I enjoy being involved in decision making, helping to shape how a product looks and works, and it makes it more of a collaborative effort, encouraging team building. You can use bits of Agile even in a waterfall project, by being proactive as a tester, challenging

the spec (nicely!), making comments on design and usability etc. In some ways the thought of changing my whole approach to Agile scares me but in another way I d love to give it a go! 4. pkr says: 8 January 2008 at 5:56 am I d recommend reading Conventional Software Testing on an Extreme Programming Team 5. Anonymous says: 12 January 2009 at 8:39 pm I think the QA/risk mitigation aspect of testing becomes overstated as you use richer web frameworks with less custom code. For example, CI is clearly a necessity for developing reliable and secure banking systems in Java/C++, but for lightweight modular web development (e.g. customisation of typical web publishing apps) mandatory CI is a victory of process over end product. This is a clear case of the tail wagging the dog and violates the first principle of the agile manifesto. Over-adherence to process in the name of agile can easily become a kind of technobeaurocracy that should be seen to fly against the spirit of agile/lean. That s not to say that developers shouldn t use tests or automate them where convenient. The big value is in TDD _as a coding technique_ to keep developers focused on features (also helping achieve the 80/20), and dev assurance that encourages refactoring. 6. Cheap Domain Names says: 16 December 2010 at 5:00 am Brilliant stuff, man! hat you have to say is really important and I am glad you took the time to share it. I hope that I can learn more about testing. According to me Software testing is provides an objective, self-sufficient view of the software to allow the business to value and understand the risks of software implementation. Thanks for sharing your opinion. I am yet to find anything as enlightening as this on the web.

Agile Principle 10: No Place For Snipers!

by Kelly Waters, 30 April 2007 | 10 Key Principles of Agile Development

Agile development relies on close cooperation and collaboration between all team members and stakeholders. Agile development principles include keeping requirements and documentation lightweight, and acknowledging that change is a normal and acceptable reality in software development. This makes close collaboration particularly important to clarify requirements just-in-time and to keep all team members (including the product owner) on the same page throughout the development. You certainly can t do away with a big spec up-front *and* not have close collaboration. You need one of them that s for sure. And for so many situations the latter can be more effective and is so much more rewarding for all involved! In situations where there is or has been tension between the development team and business people, bringing everyone close in an agile development approach is akin to a boxer keeping close to his opponent, so he can t throw the big punch! -) But unlike boxing, the project/product team is working towards a shared goal, creating better teamwork, fostering team spirit, and building stronger, more cooperative relationships. There are many reasons to consider the adoption of agile development, and in the near future I m going to outline 10 good reasons to go agile and explain some of the key business benefits of an agile approach. If business engagement is an issue for you, that s one good reason to go agile you shouldn t ignore. Kelly.