10 Key Principles of Agile Development

8/6/2019 10 Key Principles of Agile Development

1/37

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


In my mind, active user involvement is the first principle of agile development. It's not alwayspossible 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


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 200710 Key Principles of Agile Development

In agile development, requirements evolve, but timescales are fixed. This is in stark contrast to atraditional development project, where one of the earliest goals is to capture...

read more

Agile Principle 4: Agile Requirements Are Barely Sufficient



Agile development teams capture requirements at a high level and on a piecemeal basis, just-in-

time for each feature to be developed. Agile requirements are ideally visual and should...

read more

Agile Principle 5: How Do You Eat An Elephant?




2/37

How do you eat an elephant? One bite at a time! Likewise, agile development projects aredelivered 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 200710 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


In agile development, "done" should really mean "DONE!". Features developed within aniteration (Sprint in Scrum), should be 100% complete by the end of the Sprint. Too often...

read more

Agile Principle 8: Enough Is Enough!



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

read more

Agile Principle 9: Agile Testing Is Not For Dummies!



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!



Agile development relies on close cooperation and collaboration between all team members and

stakeholders. Agile development principles include keeping requirements and documentation...

read more


3/37

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 firstprinciple of agile development.

Its not always possible to have users directly involved in development projects, particularly if

the agile development project is to build a product where the r eal 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? Heres 16 reasons why!

y Requirements are clearly communicated and understood (at a high level) at the outsety Requirements are prioritised appropriately based on the needs of the user and markety Requirements can be clarified on a daily basis with the entire project team, rather than resorting

to lengthy documents that arent read or are misunderstood

y Emerging requirements can be factored into the development schedule as appropriate with theimpact and trade-off decisions clearly understood

y The right product is deliveredy As iterations of the product are delivered, that the product meets user expectationsy The product is more intuitive and easy to usey The user/business is seen to be interested in the development on a daily basisy The user/business sees the commitment of the teamy Developers are accountable, sharing progress openly with the user/business every dayy There is complete transparency as there is nothing to hidey The user/business shares responsibility for issues arising in development; its not a customer-supplier relationship but a joint team efforty Timely decisions can be made, about features, priorities, issues, and when the product is readyy Responsibility is shared; the team is responsible together for delivery of the producty Individuals are accountable, reporting for themselves in daily updates that involve the

user/business

y When the going gets tough, the whole team business and technical worktogether!Kelly.


4/37

See als :10 Key Pri i les of Agile Development

7 Resp

ses to A

ile Pri ciple 1:Acti

e User Involvement Is Imper

tive

1. Paula Thor to says:8 Mar h 2007 at6: 2 pm

There should be no users in agile. The results of agile should be so pervasive to an individualsneedsthatthe produ tis an appendage to their needs. hen wasthe lasttime youread a userguide orspecified userrequirements for your arm or leg?

On a slightly differentnote, involvementof any individualsissimply partof a full series ofactivitiesinvolved in Design Research. The artifacts of Design Research are the elementsusedto supportEvidence-Based Design.

2. KellyWater says:16 March 2007 at8:47 am

I dontagree withthis comment. Althoughscrum team is a *team* and the projectgoals are*team goals*, there mustbe a userrole in the team. Although everyone should care abouttheuser, someone musthave specific knowledge and understanding ofthe users needs, because asoftware productwith no usershas no value.

3. StephenKresssays:22 March 2007 at11:31 pm

I also disagree. There are no requirements for an arm or a leg, because you justgetone. Youdonthave a choice, you justgetone (if youre lucky).

ow can you design something thatis Pervasive to an individuals needsif you donthave auserto design for?

Since there are alwaysseveral waysto implementhow a userinteractswith an IT system, you

shouldntcounton the designerto choose the rightway. You mustask a user (and better yet, askmany users).

4. ScottW, Amblersays:28 March 2007 at12:51 am

The real issue is active stakeholder participation, notjustactive userinvolvement. A fewthoughts:1. Users are justone of many stakeholders, importantones obviously, butnotyour only ones. If


5/37

youignore otherstakeholders you putyour projectatrisk.2. Participation is betterthan simple involvement. If you dontfind waysto enable them toactively participate you putyour projectatrisk. Notonly should stakeholders provideinformation and make decisionsin a timely manner, they should also actively participate in themodeling effortthemselves. You can do this by adopting inclusive modeling toolssuch aswhiteboards and paper.

In Agile Modeling we made this very clear and included an explicitpractice, Active StakeholderParticipation. Theres a detailed article on this athttp://www.agilemodeling.com/essays/activeStakeholderParticipation.htm

Theres also a detailed article on inclusive modeling athttp://www.agilemodeling.com/essays/inclusiveModels.htm . Enjoy!

- Scott

5. wh rliwigsays:29 April 2007 at12:16 pm

Another disagree votealthoughthere is a sense in whichremoving the traditional conceptofuser as a them, as opposed to us, isuseful.

Actually, Id love to have a user guide for my arms and legs. Unfortunately theres no-onequalified to write it. I have to make do withuser guides for less customised versions of my armsand legs:health articles on the internet, medical encyclopaedias etcand if I getin real trouble Ihave to go see a developer (sorry, doctor) unfortunately I didntnegotiate the contractproperly, so I often have to waitforweeks for an appointment

6. Woutersays:8 January 2009 at3:45 pm

I think Paula was nottalking aboutagile developmentmethod, butmore aboutthe philosophybehind it. Thatthe end productshould be so intuitive to use forthe user, thathe does notfeellike a user, butis justdoing whathe does.

Ifiunderstand her correctly, im sure thatshe agreesthatthisrequires a very deepunderstanding ofthe user.

I dontthink tho, thatagile has failed ifthisis notreached. Agile hasworked, ifthe end-userishappy withthe product, even ifitcomeswith a manual.

7. JObermarksays:22 March 2009 at4:49 pm

Itis also mandatory thatthisuserrepresentative is partofthe team, and nota taskmasterwe areall serving. Presumed functionality preconceived in complete detail are notneeds.


6/37

It is not uncommon for this supposed team member to sneak off and plan out detailed task-listsfor 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. Its tempting toget a subset of the team to do this (maybe just the product owner and analyst), beca use its much

more efficient. Somehow weve 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 arisethroughout the project, the team feels a real sense of ownership. And then its doesnt seem so

expensive.

Kelly.


7/37

See also:10 Key Principles of Agile Development

5 Responses to A

ile Principle 2:A

ile Development Teams MustBe Empowered

1. IAmGM1974says:17 January 2008 at12:00 am

I understand thatthere hasto be a buy-in from all the team, butattimes I have observed thatifeveryone isinvolved into a discussion, sometimes people startpulling the discussion in differentdirections and itbecomes difficultto reach a conclusion. My question is, and I may be verywrong, but:

Could itmake sense, atleastin very initial stagesto have a sortof pre-meeting where, say theproductowner, users ortheirrepresentatives and analystsittogether and identify the featuresorsomething similar and seta tone for, or drive, the actual meeting, ratherthan everyonecoming in directly and probably having a difficultdiscussion?

2. Bruce McCarthysays:8 February 2008 at12:48 am

I have essentially the same issue. Buy-in is good butthere are some people who tend to drag thediscussion off on tangents and make group decision-making very difficult.

Also, there are some decisionswhichshould be owned by particularroles. I dontwantto spendtime discussing the doc writers opinion on the visual design orthe visual designers opinion onthe relative priority of features. The designershould own the visual design and the productownershould own the feature prioriti ation, no?


Perhapsin these caseswhere consensusishard, itis mostimportantto determine what

decisions need to be made, and which do not.

Ifthere is no consensus, there is no decision, butmaybe thatmeans youwanted too firm acontrolling hand on the groups activity, and the group isrebelling.

Isthere a smaller decision thatwill give enough direction withoutentailing the detailsthatfolksare filibustering or contending over?

In other consensus-driven contexts I also like Starhawks notion thatsome decisions cannotbemade by deliberation because they are notconcrete enough, and they should be made by oracle.


8/37

Agile promotesrefactoring, so agree when youthink you need the decision. If you cannotdecideby then, make the decision arbitrarily. Then see ifthatnets youthe data you needed to make thedecision well to begin with.

Ifso, refactor outthe old decision and implementthe new one. If not, the decision did notmatter,your arbitrary choice was as good as any other.

4. nagaraja ramayyasays:16 November 2010 at11:29 am

i, Thisisin response to the comments by Bruce:The agile teams are(should be) made up of cross functional experts, people with multipleexpertise, experienced and mature.Thusthere is no single owner, the whole team owns everyaspect.The whole team collaboratesto deliver.team membersshould plan and develop theirskillsetsso that, everyone can own anything.Thatiswhen team is completely agile, else team isrestricted by the skills ofindividuals and if an individual fall sick for a month, thatsprintfails asapartfrom owner no one can complete hiswork.The other fall outisthateach memberisworking on his own individual strand ofwork and is notreally bothered aboutteam's commitmentas a whole , ashe worries only abouthisdeliveries..thusteam becomes a group ofindividuals and can notbe called a 'team'.

5. DrillSargeant!| ReleaseInsightssays:18 February 2011 at10:07 pm

[...] core tenets of agile developmentisthatthe teams are intensely collaborative, self-managing,and empowered to achieve sprintgoals. Managementprovidesthe strategic goals,

infrastructure, and a [...]

A

ile Principle 3: Time Waits For No Man!

byKellyWaters,11 March2007|10KeyPrinciplesofAgileDevelopment

In agile development, requirementsevolve, buttimescales arefixed.


9/37

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 its 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 includeeverything they can think of in fact everything they ever dreamed of! And whats more, its all

important for the first release, because we all know Phase 2s 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 isreally 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 its 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 thats certain in life is change.

There are different mechanisms in Agile Development to handle this reality. In AgileDevelopment 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 theres enough non-mandatory 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 thecost 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, its imperative to start development


10/37

(dependencies permitting) withthe core, highestpriority features, making sure they aredelivered in the earliestiterations.

Unlike mosttraditional software developmentprojects, the resultisthatthe businesshas a fixedbudget, based on the resourcesitcan afford to investin the project, and can make plans based ona launch date thatis certain.

Kelly.


9 Responses to A

ile Principle 3: Time Waits For No Man!

1. Dave Nicolettesays:13 March 2007 at1:51 pm

hich factors are fixed and which are variable depends on circumstances. In the general case, asyousay, requirements evolve and timescales are fixed, butthisis notalwaysthe case.

Consider a projectto migrate an existing application to a differentplatform, forwhateverreason.There is no hard and fastdate when the existing application will stop functioning. Therequirements are fixed, since the goal ofthe projectisto portthe applications already-knownfunctionality to a new platform.

In thatcase, we donthave the option to drop featuresin orderto meeta date, because theported application mustprovide the same functionality asthe existing one. Butthe existingapplication can remin in production as long as necessary. So we can change the delivery date, butwe cantchange the requirements.

e could practice incremental delivery in thisscenario, possibly, depending on circumstances.

I think the key pointaboutagile work isthatwe acknowledge its notpossible to lock in *all*factorssimultaneously, astraditional managementpractices often demand. Some factorswillvary anyway, even ifwe dontwantthem too, and its betterto recogni e thatand control whichfactors can vary by intentthan itisto waitfor nature to take its course.

2. KellyWaterssays:16 March 2007 at8:49 am

In my opinion, thisscenario is no longer agile, i.e. the requirements are *fixed*. I would stilladvocate adopting many ofthe agile principlesthough, because youll getpartial advantage, andpotentially big advantage, from the visibility itbrings and the effectthishas on your abilitytomanage risks and issues early while theresstill time to react.


11/37

3. Mikesays:24 March 2007 at5:02 am

e are currently involved in justsuch a projectas dave described. e are trying to use agile

methodology nevertheless. And keep in mind, justbecause on pointor principle of agile does notapply in a particular case, thatdoesntmean thatthe restdo not. Thisis notsome sortoftestoforthodoxy!


Theresthe conceptof an iron trianglein software developmentalthoughthe real name shouldprobably be elastic triangle. The basic idea isthatatleastone ofscope, cost, orschedule mustvary otherwise quality suffers. Agilistsinsiston high quality, so were notgoing to letthatvary.

Mostagile teamswill allowthe scope (requirements) to vary butthatdoesntalwayshave to bethe case. On some projects you do in facthave fixed requirements (granted, thisis very rare).Theres no reason why you cantstill be agile in thissituation.

See http://www.ambysoft.com/essays/brokenTriangle.htmlforsome thoughts on the triangle.

- Scott

5.

Anonymoussays:

30 March 2007 at1:35 pm

i,

atthe momentI am writing my masterthesis aboutprojectmanagement. In modern timesalmostall projectshave become more complex and the future isuncertain aswell. So I compareclassical projectmanagementwith agile methods. Can you give me reasonswhy Agile ProjectManagementis discussed justin the field ofsoftware engineering? Itmustbe possible to figureoutrequirementsin other business fields aswell???

Greetings

6. KellyWaterssays:30 March 2007 at4:23 pm

i,

Althoughthe term agile seemsto have been largely adopted for agile software development, theprinciples can certainly be applied outside software developmentprojectswhere theres an


12/37

apetite forit. In factthe Scrum agile managementpractice was born outofstudies of Toyotaslean manufacturing, which you mightwantto read up on.

Kelly.

7. Diver232says:12 June 2007 at9:50 am

I always drawup a MOSCO listofrequirementswiththe users.Musthave notnegotiable, thiswill happenShould have ifwe have the timeCould have nice idea, maybe nextrelease huh?

onthave who wanted this? Timescale is fixed, butyouregularly reviewthe contents ofthelistswiththe users

8. Federico Grillisays:10 January 2008 at9:14 am

Because the only thing thats certain in life is change.owtrue.

Nexttime we could reinforce this conceptand impressstakeholders and friends by quoting Platowho understood thistwo thousand and four-hundred years ago: Everything is becoming.Nothing is. Actually, according to Plato, thisistrue only ofwordly, material things, those we getto knowthrough oursenses. owever, they are butshallow, unperfectcopies ofthe Ideal Formswhich are timeless, perfectand immutable (kind of java.lang.String) and whichwe getto know

through our mind. But, forthe sake of our agile projects, I would notsay thisto the customers. :)


Agilistsseem to come primarily from consulting backgroundswhere folks actually think projectshave boundaries.

In mostof ourindustry, thisis an illusion, a group oversees maintenance of a few differentproducts overunforeseeably long timescales. Chopping life up into projectsis lying:itlets folks

bury the costof maintenance.

So in the normal case where a productoutlives all projects, itis easierto hewto the line thatcostand time are fixed. There are n employees, and they work 40-hourweeks (until the nextrecession, when there are n-7) Reduced quality justreduces future scope, as a certainpercentage ofthe time before the nextrelease will be lostto friction. Only scope can everreallychange, and even thatisscope *as ofthe nextrelease cycle*.

I think itwould be wise of methodologiststo take thisseriously, and adjusttheir normsto thenorm. Especially agile thinkersshould, because I really think thisstyle of developmentis betterforthe long run than for a succession ofshortruns.


13/37

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

time 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 doesnt actually form part of the end

product.

Agile Development can be mistaken by some as meaning theres no process; you just make things

up as you go along in other words, JFDI! That approach is not so much Agile butFragile

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 dont 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, workingtogether 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; its a

joint activity of the team that allows everyone to contribute, challenge and understand whats

needed. And just as importantly, why.


14/37

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 usersinteraction 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 thefact its going on a card forces it to be broken down small. The advantage this has over lengthy

documentation is that its 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 dont

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 projectmanagement 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 andcompleteness. A task you cannot.

Kelly.


15/37


hatare User Storiesriting Good User Stories

13 Responses to A

ile Principle 4:A

ile RequirementsAre Barel

Su

icient


ith Agile Model Driven Development(AMDD), see http://www.agilemodeling.com/essays/amdd.htm ,we suggestthatyou do a little bitofhigh-level modeling up frontasKellysuggests. To getthe details you model storm on a just-in-time basis, thus ensuring thatyou onlyinvesttime in modeling the requirementsthatyoure actually going to implement.

In short, the advice thatKelly providesis pretty much dead on to whatthe AM community hasbeen promoting forthe pastsix years.

- Scott

2. nosnakeoilformepleasesays:1 April 2007 at5:25 pm

This looks like anotherstep around the circle. Pretty soon, we will be back where we startedwith non-agile development.

Lets look atthe well-used analogy of building a large office building.

Obviously there is quite a bitof planning thathasto be done before youstartconstruction. Infact, if you look atmostprojectsin the real world, they work the same way.

Itis only withso-called agile developmentthatwe think we can getsomething for free.

Butitis a lie.

For even if youhave everyone on yourteam thatcan build skyscrapersin theirsleep, T ISPROJECT is notthe same asthe lastproject. Itmeans a lotof planning and communicating hastobe done to getall the experts on the same page forthe currentproject. You dontgetto write afewstories and then justjump in yourheavy machinery and build the building. Unless youwantto build something horrible.

In many ways, agile developmentis aboutultimate job security. There are no realrequirements, no real specifications, nothing exceptsome ad-hoc workflows amongsta specificgroup ofindividuals. If youwantbug fixes or a new version, you are beholden to your agiledevelopers.


16/37

Maybe itshould have been called crafty development. A little honesty wouldnthurt, would it?

3. KellyWaterssays:1 April 2007 at8:09 pm

Reply to no snake oil for me please

Notsure if you actually read my post? I certainly didntadvocate jumping straightin. I wasadvocating high-level visual requirements atthe outset, and defining requirements on a just-in-time basis per feature ratherthan all up-front.

Unlike a building, software can evolve

Kelly.

4. Anonymoussays:20 July 2007 at4:31 pm

response to no snake oil.Its people like you, who think thatdeveloping software is like developing a building, thatlead usto using the waterfall method.

The reality isthatdeveloping software is nothing like developing a building. The waterfallapproachis, and alwayshas been, a square peg in a round hole. As for ultimate job securitytaking 12 monthsto finish a projectthatcan be completed in 6 by over analyzing and over

documenting sounds like ultimate job security to me.

5. Josh Milanesays:23 August2007 at5:09 pm

RIP (Rapid Iterative Prototyping) uses visual guideposts along the way aswell and may beAgile butI am becoming more and more convinced thatAgileis a catchphrase more than adiscipline.

6. KellyWaterssays:24 August2007 at6:55 am

Yes, youre right. Agileis nota discipline. Its a philosophy. A setof principles and values. Abroad approach.

Like all thingsin life, asthis broad philosophy exists, itneeds a name. Itneeds a name so we candifferentiate the approach from the more traditional (waterfall) approachto development, i.e.analyse, develop, test, etc.


17/37

If youwantto call thatname a catchphrasethats fine, butthe term seemsto undermine thefactthatthere issuch a thing as an Agile philosophy.

Agile *disciplines* are those methodologiesthatmaterially supportthese philosophies,principles and values. Forinstance Scrum, XP and DSDM, etc. Agilein itselfis nota discpline.

7. Kevinsays:11 September 2007 at1:49 pm

Although I see tremendous value in close amongstteam membersin developing software, Iwonderhowthe Agile Methodology allows forthe passing the knowledge ofhowthe systemworkswithoutthe documentation in specifications. My reservations aboutthe Agile Method isthatsomeone hasto go back later and figure outwhatwas done two orthree years back to makefeature a work the way itdoes. ithoutdocumentation a systems analysthasto spend moretime to figure outhow feature works. I am sure otherswho work in an IT shop will find thistrue.

e dontdevelop software for a large potential consumer audience, we develop software thatneedsto be used by itnernal users aswell as an existing clientbase.

8. ananthsays:5 November 2007 at9:30 pm

You are 100% right! Currently I am trying to read thruthe functionality and come up with a AS ISdocumentthatcan be ratified by the Business User, asthe currentIT group take the AGILE veryconvenitently to code and forgetthe documentpart!!Pathetic!!

9. KellyWaterssays:6 November 2007 at8:07 am

A couple of points

Firstly, I have worked on may waterfall projectswhere the spec is barely a good reflection ofthefinished system by the end ofthe project, and where commercial constraints preventus fromhaving the time to go back and update itall. In this case, having a documentthatis believed to betrue and accurate is potentially dangerous and misleading. As a consequence developers learnnotto rely on itand base their decisions on the code anyway. I do accept, however, thatthe

documentation can provide some useful context, as long asitsnottaken as gospel.

Secondly, the above commentis yetanother commentthatsuggests you didntreally read mypostand thatyoud formed your own view before youread it. I stated thatrequirements *are*captured. Its justthattheyre lightweightand visual, e.g. wireframes/storyboards, atthe outset,and details are captured per feature as you go. hy couldntthese feature documents/usecases/userstories, (orwhatever youre using) be kepttogether and provide the same contextasyoud have gotif youd written itall up front? The only difference is, writing them asthey areneeded and notall atthe beginning many months before they are developed, theyre more likelyto be in line withthe finished software.


18/37

Kelly.

10. pkrsays:4 January 2008 at6:21 pm

re: no specifications the idea isthatyou end up with executable specifications. Ideally theseare still written in such a way thatthe majority ofstakeholderswill understand them. Executablespecshave the advantage thatthe productcannotwork withoutchangesto them (assuming youwrite them in the firstplace) whereas a word doc gathering dustsomewhere may no longerrepresentwhat*is* happening. For examplessee http://www.concordion.org/FIT/Fitnesse andAPI documenting such as Sandcastle

11. Eddiesays:18 November 2008 at9:02 pm

There are trade-offs for each approach, and I have in the pastdebated the defense of eachapproach. The ultimate factorin determining howwell each approach appliesisthe acceptanceofthe company forwhich you are developing software, and the committmentfrom thatcompanyto adhere to one approach orthe other. If you are in complete control, then this discussion wouldbe invalidated. There are companieswho take comfortin waterfall because everything isexplicitly measurable, and contracts are in place thatprovide an explicitagreementforthedeliverables. Other companieswho have trusting entities, good relationships and followthesame mantra of the bestpossible software in the bestpossible time and are notunderthepressuresthatwaterfall traditionally bringsto the table are more accepting ofthe unknown(s)and are usually more in favor ofthe ability to change directions more quickly. Unless you are

working forthe government(DOE, DOD), etc., I have yetto see a developmentshop wherewaterfall or agile are followed in such a rigid manorthatyou end up with executablespecifications orthe agile requisite of change on a dime. Ultimately the tolerances ofthecompany will decide the process.


Even when the requirements are written up front, people still write user manuals. So why doboth?

hatwe need is an agile methodology thatallows for T EENTIREPRODUCT, and thatincludesthe user-training material, to be delivered on schedule. Then folks cannotcomplain laterthatfunctionality is notdocumented.

I think this precludes an old-fashioned user manual, and requires creative people in thedocumentation community to come on board.

e need to think throughsome kind of knowledge web thatcan capture the changingrequirements ata user level and still be rightatthe end.


19/37

13. A_flj_says:21 August2009 at12:50 pm

I agree with no snake oil with one importantdifference:whatprogrammers build are the

skyscraper's blueprints. The compileristhe one building the skyscraper.

Thatbeing said: blueprints can evolve. owever, once the compiler orthe builderssetthem instone, the acutal installed program/skyscraper cannotchange anymore (unlessrebuilt/reinstalled).

hatwe are arguing aboutis a methodology to make the blueprints.

Car manufacturers make many sets of prototypes and blueprints before they getto the finalversion. Archtiects and civil engineers lessso they testeach piece individually.

Butkitchen appliances makers do little of either. They may make a few models, butforthem itisessentially a talented industrial designer designing something smart.

IMO, it's more or lessthe same withsoftware. Itall depends on whatprecisely we are doing.

Now, there are only very fewskyscrapers designed each year, when compared to car models, andeven car modelsthere are few a year, when compared forinstance with coffee makers a coffeemaker being one ofthe more complicated kitchen appliances. hile the skyscraper designersmay need an agile process, because the costs caused by them iterating several times overthewhole design are neglectable when comparted to the benefitsthe skyscraperwill bring in,somebody designing and building a custom kitchen furniture for a newhouse will probably notgetfinancing for doing the design ten times over, withthree prototypesthrown in between.

Therefore, agile is less of a choice there. Besides, there are highly skilled architects and civilengineersworking atthe plans forthe skyscraper, and possibly justa carpenterworking by theadvice of an interior designer furnishing the kitchen, so probably there won'tbe the skillsinplace to try outseveral variants, besidesthe customers notwanting to pay for morethan justtheminimum costrequired to getthe job done.

Nevertheless, all thatagile methods advocatestalk aboutare skyscraper plans. hichis OK, aslong asthey don'ttry to getme buy into agile methodswhile I'm doing my custom intranetdatabase interfaces for paying customers.

A

ile Principle 5: How Do You EatAn Elep

ant?

byKellyWaters,25March2007|10KeyPrinciplesofAgileDevelopment


20/37

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 Reduced risk: clear visibility of whats completed to date throughout a projecty Increased value: delivering some benefits early; being able to release the product whenever its

deemed good enough, rather than having to wait for all intended features to be ready

y More flexibility/agility: can choose to change direction or adapt the next iterations based onactually seeing and using the software

y Better cost management: if, like all-too-many software development projects, you run overbudget, some value can still be realised; you dont 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 its

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 youve 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 ofvalue


21/37

to the user,and alwaysdeliverablesratherthan activitiesso you can kick the tyres and judgetheir completeness, quality and readiness forrelease.

These are importantcharacteristics ofiterative, feature-driven development and theyreessential if you plan to deliverin fixed timescales one ofthe 10 key principles of agile softwaredevelopment.

Kelly.

6 Responses to A

ile Principle 5: How Do You EatAn Elep

ant?

1. Mikesays:26 March 2007 at5:34 pm

iKelly. I posted a link from my blog to yours. Thanks forthe information.

2. Anonymoussays:5 July 2007 at2:14 am

Very nice and succinct. I will borrowsome language for a presentation I need to give!Thanks.

3. srutanjaysays:14 May 2008 at9:03 am

ell, when changeshappen over a small discussion or verbally itisimportantthatthose aretracked. how are the changes documented. Atthe end ofthe day itisimportantto track therequirements, thoughitmay keep changing.Thanks.

4. KellyWaterssays:14 May 2008 at4:42 pm

isrutanjay

Yousay itsimportantto track the requirements why isthat?

Kelly.

5. srutanjaysays:15 May 2008 at9:39 am


22/37

Hi kelly,

First, when requirements keep getting modified due to iterative method of development, onemay need to see howthe final requirementhasshaped up as compared to the initial one.

Secondly, astime and costare fixed, some ofthe requirements may be differred for a later

release.

Thanks.

6. KellyWaterssays:15 May 2008 at10:32 am

Hisrutanjay

Re your firstpoint, I have worked in developmentfor many years and the only reason Ive everhad to do thisisto argue with people aboutwhy were late. In agile development, the keystakeholders (especially the productowner) should have been involved throughout, so thisriskis mitigated. In my experience of agile, I dontthink Ive seen this need once as aresult.

If any requirements are defered for a laterrelease, they can simply be captured on the productbacklog and a newuserstory written nearerthe time of development.

Its a very interesting pointthough. Has anyone else gota view on this?

Kelly.

A

ile Principle 6: FastBut NotSo Furious

byKellyWaters,31 March2007|10KeyPrinciplesofAgileDevelopment

Agile developmentis all aboutfrequentdelivery of products. In a truly agile world, gone are thedays ofthe 12 month project. In an agile world, a 3-6 month projectisstrategic!


23/37

Nowhere is this more true than on the web. The web is a fast moving place. And with the luxury

of centrally hosted solutions, theres every opportunity 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, its increasingly accepted for products to be released early (when theyre basic, not

when theyre faulty!). Particularly in the Web 2.0 world, its a kind of perpetual beta. In thissituation, why wouldnt you want to derive some benefits early? Why wouldnt you want to hear

real user/customer feedback before you build everything? Why wouldnt you want to look atyour web metrics and see what works, and what doesnt, 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 howfrequent is *frequent*?

Scrum says break things into 30 day Sprints. Thats 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 frequentI think. The overhead of releasing the sof tware is just too large to bepractical on such a regular basis.

But consider a web site, a web-based product or even more dynamic something like my blog.

Theres no rollout overhead its an automated central deployment to all users, and for the blog

its a single click. No-ones paying for the service. If somethings wrong, no-one dies. And it can be

rolled back as quickly as its 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 onthe user experience, and the users behaviour, through metrics within 2 hours and on an

ongoing basis.

In that scenario, 30 days is a lifetime!

Competitors wont wait. Speed-to-market is a significant competitive edge. The value of first-

mover advantage is potentially enormous. Whilst its 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 Ive described above.Think about whats right for you; your organisation; your product; your market; your customers.

Think about whats right for *you*, in your *particular situation*. There is no right or w rong

answer. Only what works for you, and what doesnt.

What is fairly important is to make this a positive decision to decide whats 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. Itallows your launch events, marketing campaigns, etc to be planned. And because agile

development works to a fixed timescale, these plans are assured.


24/37

A regularrelease cycle also allows youto learn more effectively. Your estimating mightbe good,itmightbe bad. Hopefully its atleastconsistent. If you estimate features ata granular level(ideally lessthan 1 day) and track your velocity (how much of your estimate you actuallydelivered in each Sprint), in time youll begin to understand your *normal* delivery rate. Andwhen youunderstand thiswell, youll be surprised how predictable you can be.

And lets face it, managing expectationsisreally all aboutpredictability. If people knowwhattoexpect, theyre generally happy. Ifthey dont, theyre nothappy. Maybe even furious!

So, in agile development, focus on frequentdelivery of products. And perhaps even moreimportantly, focus on consistentdelivery of products.

Kelly.

3 Responses to A

ile Principle 6: FastBut NotSo Furious

1. DerekMorrisonsays:3 April 2007 at1:50 pm

I think the constantdelivery makes goodbusiness sense the ability for all stakeholders:sales,marketing etc to plan ahead and synchronise their planswithtechnical delivery offeatures/projects also makes good sense. I have posted an article on my blog a few days ago thatdiscussesgoodbusiness sense and tec

!

nical sense coming togetherto make.

Derek:

All AboutProductManagement

2. MishkinBerteigsays:14 April 2007 at9:27 pm

In my experience, which covers everything from large $100M+ projectsto tiny projects, 30calendar daysisthe absolute maximum Sprintoriteration length. Mostorganizationssettleinto a comfortable length of 10 working days. Letting your Sprintlength be too long justleavesall sorts of problemsuncovered. The shorterthe sprintlength, the faster you learn to do short

sprints!

3. MichaelJamessays:16 April 2007 at2:28 am

One thing you mighthave missed here isthe distinction between Sprintand Release. Scrumdoesntrequire a release every Sprint, justa demonstration ofpotentiallyshippableproductincrement. Potentially shippable meanswe could bring itinto shippable form after onestabilizationsprint.


25/37

As Mishkin wrote, Id 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 doesnt really mean DONE!. It doesnt mean tested.It doesnt necessarily mean styled. And it certainly doesnt 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. Certainlythats the case on BAU (Business As Usual) changes to existing products. On projects its not

feasible to do a release after every Sprint, however completing each feature in turn enables a

very precise view of progressand how far complete the overall project really is or isnt.

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 theres any doubt aboutwhat activities should or shouldnt 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 youre ever unsure if a

feature is done enough, ask one simple question Is this feature ready to be shipped?.

Its also important to reallycomplete 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


26/37

importantto ensure the overall productisin a shippable state atthe end ofthe Sprint, notin astate where multiple features are 90% complete oruntested, asis more usual in traditionaldevelopmentprojects.

In agile development, donereally should mean DONE!.

Kelly.

See also:10 Key Principles of Agile Software DevelopmentTime waits for no man!How dyou eatan elephant?Fastbutnotso furious!

12 Responses to Agile Principle 7: Done Means D " NE!

1. JonahDempcysays:8 April 2007 at9:24 pm

I agree entirely. One way I have heard itcompared isto say, there is done and then there isdone done done. The difference isthatthe former mightbe when you feel thatyou are finishedworking on it, butdone done done meansithas been reviewed (both design review and codereview), ithas been tested (by yourself and hopefully a QA team) and itisready to release inevery possible sense ofthe term.

2. Krissays:8 April 2007 at11:32 pm

I certainly agree with your posting, butas I posted onhere, I see a large problem getting somefeaturesto shippable in a shortamountoftime.

If youhave 1 userstory thattakesthe team 2 sprintsto complete yousurely cantbe done attheend of 1 sprint. And ifthe feature isntshippable till say 5userstories are complete then you maybe able to only getto 2 ofthem persprint, and youwouldntbe shippable till sprint3.

Id be interested on yourthoughts.


Firstof all, you can cheata bit:-)

In my mind, a userstory equals a feature, so in the case where there are 5userstories, treatas5features.


27/37

Ifthe productisntshippable until all 5 features are complete, because itdoesntreally makesense piecemeal, thats fine.

Itsthe feature thathasto be shippable quality; notnecessarily thatitwould be appropriate toship the productafter every feature.

But, when yousay a feature is complete, itmustreally be shippable once the dependentfeaturesare also complete.

ith features broken down into theirsmallestpossible pieces, if youstill have 1 feature thatspans 2 sprints, youshould seriously considerwhether yoursprints are too shortfor yoursituation.

Your product, tools, team size, skills, features, etc, etc determine whatis an optimum sprintlength for *you*

Hope thishelps

Kelly.


If youwantto discussthisissue or otherswith your peers, why notgive the forum a try

http://www.groups.google.com/group/allaboutagile

5. Anonymoussays:10 April 2007 at9:21 pm

Fine forsoftware development, butI think Google and 37 signalswould differ on this, itneedstobe still bug free and done, butnot100% done, if Google keptGmail in secretuntil its outof betaitwouldntbe as much of a success.

6. KellyWaterssays:14 April 2007 at7:13 am

I agree. You donthave to develop all the intended features. You donteven have to make thefeatures as functionally rich as youintend to. Butyou do need to make sure thatthe featuresdeveloped in *each* Sprint/iteration are DONE!, including testing, styling, user acceptance, etc.

7. Peter's mommysays:28 October 2007 at11:30 am


28/37

Our problem isthe developers lacking experience outin the field doesntreally understand theeffectofwhatthey conceive as a minor problem or glitch. hile other developers dive intodetails. tiny details.

8. pkrsays:8 January 2008 at5:33 am

I agree thatthere is a need to make done mean thatithas completed its analyse to testcyclebutI dontthink itmeansthe feature is done. I like the idea ofscale (see JeffPatton) where afeature can be splitinto separate deliverable independently useful parts. I.e. you can delivertheessentials of a feature in incrn so thatyou could consideritusable. However, youstill intend toimprove itin incrn+1. (I dontbelieve thatthese are typically newstories).

9. Anonymoussays:10 January 2008 at5:43 pm

hathappenswhen you complete yourstories nearthe end ofthe iteration and itwill take QAseveral daysto verify the story is complete and working? In the meantime you are planning forthe nextiteration and have no idea if youreally are complete, until QA catchup all the time?

10. KMKsays:9 August2008 at5:48 am

I have exactly the same scenario in my team(As mentioned by anonymousreader above).Currently, we moved testing to nextsprint. But whatifthe testing team finds outa lots of bugsby the end oftesting? Shud the bug fixing be moved to anothersprint? Overall extending itto 3sprints!!

11. Anonymoussays:29 August2008 at10:40 pm

Youshouldntleave several days oftesting until the end ofthe iteration. The testing for eachtask/deliverable within an iteration should be done assoon as possible (starttesting on the first

day if you can). As you approachthe end of youriteration, youshould already have everythingtested and all bugs fixed.

12. Jansays:21 October 2009 at11:56 am

I'm very interested in your point"complete each feature before moving on to the next".


29/37

We are building a shared agile development team, that is we have multiple projects with multipleproject owners. I can imagine situation that the team completes an underestimated feature. Thiscauses 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 aboutHow To Share An Agile Development Team. Do youknow any other sources?

Agile Principle 8: Enough Is Enough!

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

Paretos 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!

Paretos 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 hind-

sight) *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 isnt 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%?


30/37

Now that doesnt 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 notreally up to scratch. Vista, for those that havent tried it, looked rather slow even on a laptop with

GB RAM! And apart from being slightly prettier didnt 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, Microsofts own research found that the average

user ofWord uses only *8%* of the functionality. Thats 8%! And I wouldnt mind betting at least80% 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 wewill never know.

Its also worth considering the impact on user experience. Google has shown us that users oftenprefer apps that do just what you want. Thats *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 youre 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 its 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


31/37

9 Responses to Agile Principle 8: Enough Is Enough!

1. Siobhansays:2 May 2007 at7:02 pm

The 80/20 rule is one often applied in leadership and managementdevelopmentand isthereforelikely to be a conceptthatcan be rolled outto customersin a mannerin whichthey feelconfident.

Itis also interesting to considerthe useability of developed software from a user perspective ifI am never going to use a specific piece of functionality then itsrequirementis questionable.

In caseswhere software is designed in a mannerthatwill allowincreased or even alteredfunctionality in the future, ensuring thatusers are enthusiastic and comfortable with commontasks during early iterations buildstrustand confidence in the development. This often resultsinincreased user participation, better feedback and ultimatley and cleaner and bettersolution.

So all in all, I agree, the Pareto principle can be a powerful tool for organising iterations, and alsocommunicating those to the clientand end user.

2. Damon Poolesays:13 May 2007 at3:52 am

Greatpost!

I suggestthatyou donthave to knowup frontwhatthat20% isrightoutofthe gate. Even if youjustguesswhatitis, thats probably good enough. Once youhave that20% to show, youll gettheuser feedback thatwill help you make an even better guessin the nextrelease. Plus, if youcantguesswhatthat20% is, perhaps you are in the wrong marketor need to spend more timelearning aboutyour market!

3. Anonymoussays:23 July 2007 at10:06 pm

ell, itseemsto me thatone could know 80% ofthe 80% thatneedsto be done up front, bydoing 20% ofthe research youd have to do to getthe other 20%.

And so on.

4. Anonymoussays:29 April 2008 at3:52 pm


32/37

Thisis a fine concepton paper, yetI rarely find real world examplesin which demonstrateHOyousave 80% ofthe time. In every projectIve worked on (software projectthatis), its notthecase that80% ofthe requested features can easily be splitoutand delivered in shortorder. The80/20 rule actually endsup meaning 80% ofthe code is easy to write, given a reasonablearchitectural and design passwas done. Butthere isthe final 20%, required in orderto gettheapplication to actually boot, run, stay running, and have a modicum of performance. Thishas

always been the case regardless ofhow much I minimize scope to getthingsoutthe door faster.80% bang for 20% effortdoes NOT logically imply thatyou can getaway with notdoing the 20%,unless you are writing vaporware, proof of concepts, or college projects.

5. Pedrosays:14 August2008 at3:15 am

ell, maybe you are justusing the principle withthe wrong fact. I mean, why notdevelop 20 %ofthe featuresthatadd 80 % ofthe software value.

This approach can be hold on whatPoppendieck reports on their Lean Software Development.They say thata Standish Group study found that45% ofsoftware features are neverused and19% are rarely used. So, 64% ofthe features youimplemented in the software does notaggregate no value to the product. SO, how many thatcould youhave saved focusing on whatreally adds value to the product.

6. Anonymoussays:9 September 2008 at9:09 am

ell, and I alwaysthoughtthatimplementing 90% ofthe featurestake up 90% ofthe time andthe other 10% require the other 90% ofthe time.I guess I should try outthis agilething, ifthatbringsthatdown to 80% :-)(Thanks forthe nice article, btw. :-)

7. JObermarksays:24 March 2009 at12:12 am

As a mathematician, I feel obligated to pointoutthatalmosteveryone misunderstandsthenature ofstatistical laws. Awareness ofthe truth of an inescapable trend does notmean you can

escape the trend!

Youwill still mostlikely spend 80% of your efforton whatyou considerto be only 20% ofthedifficulty, even if you keep trying to avoid the perceived over-concentration of effort.

Therefore avoiding unwanted featureshas nothing to do withthe real, original 80/20 rule.Neither doesthe idea ofrapid rolloutand laterstabilization.

There is no 80% ofthe work thatcan be saved orreallocated by finding some pernicious 20% ofthe problem space thatway lie the dragons of analysis paralysis and heavy protocol.


33/37

Paretosis a law of a statistical nature, notan observation ofhuman decision-making processes.So we need to work withthe truthinstead of againstit. Aswork drawstime and itsrequirementsjustwontsettle down, dontresentitortake itpersonally. The perceived disparity ofreturnsispreordained, and will average outto 4-to-1, whatever you do. (And thatis lovely, because itistrue. Platos God saysso.)

So detach from it. Do notbe led to considerunexpectedly hard work more important, or less. Donotgive itmore scrutiny and criticism, or less.

Do notdeclare war on itor dig in to discoverthe cause ofthis perversity. Doing so is exactly thekind ofreflexive over-analysisto which agile technologies are meantto be an anodyne.

8. Alena Shechkovasays:1 December 2009 at9:12 am

Thanks forthe fantastic article! The Pareto's principle should be undoubtedly taken intoconsideration when developing software, because we are catering forthe end userin fact. Itwould be greatif all the clientsunderstood it.

9. Anonymoussays:4 May 2010 at10:40 am

I only read 20% ofthe article. I guess I got80% ofthe contentthatway.

Agile Principle 9:Agile Testing Is NotForDummies!

byKellyWaters,22 April2007|10KeyPrinciplesofAgileDevelopment

In agile development, testing isintegrated throughoutthe lifecycle; testing the softwarecontinuously throughoutits development.


34/37

Agile developmentdoes 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 allfeatures 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 its appropriate.

The XP (Extreme Programming) agile methodology goes further still.XP recommends test driven

development, writing tests before writing the software.

But testing shouldnt only be done by developers throu ghout the development. There is still a

very important role for professional testers, as we all know developers cant 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 therequirements.

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 dont know precisely what theyre testing for. They dont 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 thatsoftware 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, theres 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 its good quality.

Agile testing therefore calls for more judgement from a tester, the application of more expertise

about whats good and whats not, the ability to be more flexible and having the confidence to

work more from your own knowledge of what good looks like. Its certainly not just a case offollowing a test script, making sure the software does what it says in the spec.


35/37

And forthese reasons, agile testing is notfor dummies!

Kelly.

For furtherreading aboutagile principles, see 10 Key Principles of Agile Software Development.

6. Responses to Agile Principle 9:Agile Testing Is NotForDummies!

1. Piersjsays:27 April 2007 at11:59 am

I came acrossthis netcase on agile testing which mightbe ofinterest?

http://parlezuml.com/blog/?postid=394

2. Paul Littleburysays:30 June 2007 at2:00 pm

Agile a good methodology, buthardly re-invents any testing rules. Testing should always beinvolved from the outset, any software developmentmanual from 1980s onwardswill say that.Developersseem to have forgotten their own training.

Modern software developmenthappensin tighter more rapid cycles itsthatsimple. hatis

generally missed outfrom Agile, whichisthe the whole point isinvolvementby the client, orthe end-useris no such clientexists. Making software quickly is notthe focus of Agile, itsretaining control and ensuring thatwhata clientwantsiswhatthey get, and thatchanges can bemade mid-stream with minimal impact.

Have a look atusabilitymustdie.com, asitcontainssome good reality-checks for developers. NotAgile specific, butsuccinctly summarisesto crisisin modern development. Developmenthasbecome fartoo smug and self-congratulatory to the pointof dictating to userswhatthey want,instead ofLISTENING.

3. SteveWatsonsays:19 July 2007 at9:58 am

I mustadmitthatafter 18 yearsin a waterfall approach, itwould be astruggle to change to anAgile approach. However I can see the benefits ofthrowing offthe shacklesthatbind us astesters and starting to have more impacton whatis produced.

e have come a long way from throwing code attesters atthe end ofthe dev cycle, and testersonly being used to matchresults versusspec. I enjoy being involved in decision making, helpingto shape how a productlooks and works, and itmakesitmore 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


36/37

the spec (nicely!), making comments on design and usability etc.In some waysthe thoughtof changing my whole approachto Agile scares me butin anotherwayId love to give ita go!

4. pkrsays:8 January 2008 at5:56 am

Id recommend reading Conventional Software Testing on an Extreme Programming Team

5. Anonymoussays:12 January 2009 at8:39 pm

I think the QA/risk mitigation aspectoftesting becomes overstated as youuse richerwebframeworkswith less custom code. For example, CI is clearly a necessity for developing reliable

and secure banking systemsin Java/C++, butfor lightweightmodularweb development(e.g.customisation oftypical web publishing apps) mandatory CI is a victory of process over endproduct. Thisis a clear case ofthe tail wagging the dog and violatesthe firstprinciple ofthe agilemanifesto. Over-adherence to processin the name of agile can easily become a kind oftechno-beaurocracy thatshould be seen to fly againstthe spiritof agile/lean.

Thats notto say thatdevelopersshouldntuse tests or automate them where convenient. Thebig value isin TDD _as a coding technique_ to keep developers focused on features (also helpingachieve the 80/20), and dev assurance thatencouragesrefactoring.

6. C

heapD

omain Namessays:

16 December 2010 at5:00 am

Brilliantstuff, man! hatyouhave to say isreally importantand I am glad youtook the time toshare it. I hope thatI can learn more abouttesting. According to me Software testing is providesan objective, self-sufficientview ofthe software to allowthe businessto value and understandthe risks ofsoftware implementation. Thanks forsharing your opinion. I am yetto find anythingas enlightening asthis on the web.

Agile Principle 10: No Place ForSnipers!

byKellyWaters,30 April2007|10KeyPrinciplesofAgileDevelopment


37/37

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 cant do away with a big spec up-front *and* not have close collaboration. You need

one of them thats 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 keepingclose to his opponent, so he cant 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

Im 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, thats one good reason to go agile you shouldntignore.

Kelly.

Documents

10 Key Principles of Agile Development