One Stop Agile software development explained

8/7/2019 One Stop Agile software development explained

http://slidepdf.com/reader/full/one-stop-agile-software-development-explained 1/17

Agile software development

Agile software development is a conceptual framework for software engineering thatpromotes development iterations throughout the life-cycle of the project.There are many agile development methods; most minimize risk by developing software inshort amounts of time. Software developed during one unit of time is referred to as aniteration, which may last from one to four weeks. Each iteration is an entire software project:including planning, requirements analysis, design, coding, testing, and documentation. An

iteration may not add enough functionality to warrant releasing the product to market but thegoal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.Agile methods emphasize face-to-face communication over written documents. Most agileteams are located in a single open office sometimes referred to as a bullpen. At a minimum,this includes programmers and their "customers" (customers define the product; they may beproduct managers, business analysts, or the clients). The office may include testers, interactiondesigners, technical writers, and managers.Agile methods also emphasize working software as the primary measure of progress. Combinedwith the preference for face-to-face communication, agile methods produce very little writtendocumentation relative to other methods. This has resulted in criticism of agile methods asbeing undisciplined.

Contents:HistoryPrinciples behind agile methods — The Agile ManifestoComparison with other methodsSuitability of agile methodsAgile dataAgile methods and method tailoringAgile methodsMeasuring agilityCriticismAgile Principles

History

Agile software development is a conceptual framework for software engineering thatpromotes development iterations throughout the life-cycle of the project.

There are many agile development methods; most minimize risk by developing software inshort amounts of time. Software developed during one unit of time is referred to as aniteration, which may last from one to four weeks. Each iteration is an entire software project:including planning, requirements analysis, design, coding, testing, and documentation. Aniteration may not add enough functionality to warrant releasing the product to market but the

goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.

Agile methods emphasize face-to-face communication over written documents. Most agileteams are located in a single open office sometimes referred to as a bullpen. At a minimum,this includes programmers and their "customers" (customers define the product; they may beproduct managers, business analysts, or the clients). The office may include testers, interactiondesigners, technical writers, and managers.

of 17 50405959.doc

http://www.onestoptesting.com/agile-testing/


http://www.onestoptesting.com/agile-testing/history.asp

http://www.onestoptesting.com/agile-testing/principles.asp

http://www.onestoptesting.com/agile-testing/comparison.asp

http://www.onestoptesting.com/agile-testing/suitability.asp

http://www.onestoptesting.com/agile-testing/agile-data.asp

http://www.onestoptesting.com/agile-testing/agile-methods.asp

http://www.onestoptesting.com/agile-testing/methods.asp

http://www.onestoptesting.com/agile-testing/measuring-agility.asp

http://www.onestoptesting.com/agile-testing/criticism.asp

http://www.onestoptesting.com/agile-testing/agile-principles.asp


http://www.onestoptesting.com/agile-testing/history.asp

http://www.onestoptesting.com/agile-testing/principles.asp

http://www.onestoptesting.com/agile-testing/comparison.asp

http://www.onestoptesting.com/agile-testing/suitability.asp

http://www.onestoptesting.com/agile-testing/agile-data.asp

http://www.onestoptesting.com/agile-testing/agile-methods.asp

http://www.onestoptesting.com/agile-testing/methods.asp

http://www.onestoptesting.com/agile-testing/measuring-agility.asp

http://www.onestoptesting.com/agile-testing/criticism.asp

http://www.onestoptesting.com/agile-testing/agile-principles.asp




Agile methods also emphasize working software as the primary measure of progress. Combinedwith the preference for face-to-face communication, agile methods produce very little writtendocumentation relative to other methods. This has resulted in criticism of agile methods asbeing undisciplined.

The modern definition of agile software development evolved in the mid 1990s as part of areaction against "heavyweight" methods, as typified by a heavily regulated, regimented, micro-managed use of the waterfall model of development. The processes originating from this use of

the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with theways that software developers actually perform effective work. A case can be made that agileand iterative development methods are a return to development practice seen early in thehistory of software development. Initially, agile methods were called "lightweight methods." In2001, prominent members of the community met at Snowbird, Utah, and adopted the name"agile methods." Later, some of these people formed The Agile Alliance, a non-profitorganization that promotes agile development.

Methodologies similar to Agile created prior to 2000—include Scrum (1986), Crystal Clear,Extreme Programming (1996), Adaptive Software Development, Feature Driven Development,and DSDM (1995).

Extreme Programming (usually abbreviated as "XP") was created by Kent Beck in 1996 as away to rescue the struggling Chrysler Comprehensive Compensation (C3) project. While thatproject was eventually canceled, the methodology was refined by Ron Jeffries' full-time XPcoaching, public discussion on Ward Cunningham's Portland Pattern Repository wiki and furtherwork by Beck, including a book in 1999. Elements of Extreme Programming appear to be basedon Scrum and Ward Cunningham's Episodes pattern language.

Principles

Agile methods are a family of development processes, not a single approach to softwaredevelopment. In 2001, 17 prominent figures in the field of agile development (then called"light-weight methodologies") came together at the Snowbird ski resort in Utah to discuss waysof creating software in a lighter, faster, more people-centric way. They created the AgileManifesto, widely regarded as the canonical definition of agile development, and accompanyingagile principles.

Some of the principles behind the Agile Manifesto are

• Customer satisfaction by rapid, continuous delivery of useful software• Working software is delivered frequently (weeks rather than months)• Working software is the principal measure of progress• Even late changes in requirements are welcomed• Close, daily cooperation between business people and developers• Face-to-face conversation is the best form of communication• Projects are built around motivated individuals, who should be trusted• Continuous attention to technical excellence and good design• Simplicity• Self-organizing teams• Regular adaptation to changing circumstances

of 17 50405959.doc



The publishing of the manifesto spawned a movement in the software industry known as agilesoftware development.

In 2005, Alistair Cockburn and Jim Highsmith gathered another group of people — managementexperts, this time — and wrote an addendum, known as the PM Declaration of Interdependence.

Comparison with other methods

Agile methods are sometimes characterized as being at the opposite end of the spectrum from"plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies thatagile methods are "unplanned" or "undisciplined". A more accurate distinction is to say thatmethods exist on a continuum from "adaptive" to "predictive". Agile methods exist on the"adaptive" side of this continuum.

Adaptive methods focus on adapting quickly to changing realities. When the needs of a projectchange, an adaptive team changes as well. An adaptive team will have difficulty describingexactly what will happen in the future. The further away a date is, the more vague an adaptive

method will be about what will happen on that date. An adaptive team can report exactly whattasks are being done next week, but only which features are planned for next month. Whenasked about a release six months from now, an adaptive team may only be able to report themission statement for the release, or a statement of expected value vs. cost.

Predictive methods, in contrast, focus on planning the future in detail. A predictive team canreport exactly what features and tasks are planned for the entire length of the developmentprocess. Predictive teams have difficulty changing direction. The plan is typically optimized forthe original destination and changing direction can cause completed work to be thrown awayand done over differently. Predictive teams will often institute a change control board to ensurethat only the most valuable changes are considered.

Agile methods have much in common with the "Rapid Application Development" techniquesfrom the 1980/90s as espoused by James Martin and others

Contrasted with other iterative development methods

Most agile methods share other iterative and incremental development methods' emphasis onbuilding releasable software in short time periods. Agile development differs from otherdevelopment models as in this model time periods are measured in weeks rather than monthsand work is performed in a highly collaborative manner, and most agile methods also differ bytreating their time period as a strict timebox.

Contrasted with the waterfall model

Agile development does not have much in common with the waterfall model. As of 2004, thewaterfall model is still in common use. The waterfall model is the most predictive of themethodologies, stepping through requirements capture, analysis, design, coding, and testing in

of 17 50405959.doc



a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts—requirement specifications, design documents, test plans, code reviews and the like.

The main problem of the waterfall model is the inflexible nature of the division of a project intoseparate stages, so that commitments are made early on, and it is difficult to react to changesin requirements. Iterations are expensive. This means that the waterfall model is likely to beunsuitable if requirements are not well understood or are likely to change radically in the courseof the project.

Agile methods, in contrast, produce completely developed and tested features (but a very smallsubset of the whole) every few weeks or months. The emphasis is on obtaining the smallestworkable piece of functionality to deliver business value early, and continually improvingit/adding further functionality throughout the life of the project.

Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cyclein every iteration. Other teams, most notably Extreme Programming teams, work on activitiessimultaneously.

Contrasted with Cowboy Coding

Cowboy coding is the absence of a defined method: team members do whatever they feel isright. Agile development's frequent re-evaluation of plans, emphasis on face-to-facecommunication, and relatively sparse use of documents sometimes causes people to confuse itwith cowboy coding. Agile teams, however, do follow defined (and often very disciplined andrigorous) processes.

As with all methodologies, the skill and experience of the users define the degree of successand/or abuse of such activity. The more rigid controls systematically embedded within aprocess offer stronger levels of accountability of the users. The degradation of well-intendedprocedures can lead to activities often categorized as cowboy coding.

Suitability of agile methods

Although agile methods differ in their practices, they share a number of commoncharacteristics, including iterative development, and a focus on interaction, communication, andthe reduction of resource-intensive intermediate artifacts. The suitability of agile methods ingeneral can be examined from multiple perspectives. From a product perspective, agilemethods are more suitable when requirements are emergent and rapidly changing; they areless suitable for systems that have high criticality, reliability and safety requirements, thoughthere is no complete consensus on this point. From an organizational perspective, the suitabilitycan be assessed by examining three key dimensions of an organization: culture, people, andcommunication. In relation to these areas a number of key success factors have been identified(Cohen et al., 2004):

• The culture of the organization must be supportive of negotiation• People must be trusted• Fewer staff, with higher levels of competency• Organizations must live with the decisions developers make

of 17 50405959.doc



• Organizations need to have an environment that facilitates rapid communicationbetween team members


The most important factor is probably project size. As size grows, face-to-face communicationbecomes more difficult. Therefore, most agile methods are more suitable for projects with smallteams, with fewer than 20 to 40 people. Large scale agile software development remains anactive research area.

Another serious problem is that initial assumptions or overly rapid requirements gathering upfront may result in a large drift from an optimal solution, especially if the client defining thetarget product has poorly formed ideas of their needs. Similarly, given the nature of humanbehaviour, it's easy for a single "dominant" developer to influence or even pull the design of thetarget in a direction not necessarily appropriate for the project. Historically, the developers can,and often do, impose solutions on a client then convince the client of the appropriateness of thesolution, only to find at the end that the solution is actually unworkable. In theory, the rapidlyiterative nature should limit this, but it assumes that there's a negative feedback, or even

appropriate feedback. If not, the error could be magnified rapidly.

This can be alleviated by separating the requirements gathering into a separate phase (acommon element of Agile systems), thus insulating it from the developer's influence, or bykeeping the client in the loop during development by having them continuously trying eachrelease. The problem there is that in the real world, most clients are unwilling to invest thismuch time. It also makes QAing a product difficult since there are no clear test goals that don'tchange from release to release.

In order to determine the suitability of agile methods individually, a more sophisticated analysisis required. The DSDM approach, for example, provides a so-called ‘suitability-filter’ for thispurpose.

The DSDM and Feature Driven Development (FDD) methods, are claimed to be suitable for anyagile software development project, regardless of situational characteristics.


A comparison of agile methods will reveal that they support different phases of a softwaredevelopment life-cycle to varying degrees. This individual characteristic of agile methods can beused as a selection criterion for selecting candidate agile methods. In general a sense of projectspeed, complexity, and challenges will guide you to the best agile methods to implement andhow completely to adopt them.

Agile development has been widely documented (see Experience Reports, below, as well asBeck, and Boehm and Turner as working well for small (<10 developers) co-located teams.Agile development is expected to be particularly suitable for teams facing unpredictable orrapidly changing requirements.

Agile development's applicability to the following scenarios is open to question:

of 17 50405959.doc



• Large scale development efforts (>20 developers), though scaling strategies andevidence to the contrary have been described.

• Distributed development efforts (non-co-located teams). Strategies have been describedin Bridging the Distance and Using an Agile Software Process with Offshore Development

• Mission- and life-critical efforts• Command-and-control company cultures

It is worth noting that several large scale project successes have been documented by

organisations such as BT which have had several hundred developers situated in the UK,Ireland and India, working collaboratively on projects and using Agile methodologies. Whilequestions undoubtedly still arise about the suitability of some Agile methods to certain projecttypes, it would appear that scale or geography, by themselves, are not necessarily barriers tosuccess.

Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive("agile") and predictive ("plan-driven") methods. The authors suggest that each side of thecontinuum has its own home ground :

Agile home ground:

•

Low criticality• Senior developers• Requirements change very often• Small number of developers• Culture that thrives on chaos

Plan-driven home ground:

• High criticality• Junior developers• Requirements don't change too often• Large number of developers•

Culture that demands order

Agile data

One of the most challenging parts of an agile project is being agile with data. Typically this iswhere projects hit legacy systems and legacy requirements. Many times working with datasystems requires lengthy requests to teams of specialists who are not used to the speed of anagile project and insist on exact and complete specifications. Typically the database world willbe at odds with agile development. The agile framework seeks as much as possible to removethese bottlenecks with techniques such as generative data models making change fast. Models

for data serve another purpose, often a change of one table column can be a critical issuerequiring months to rebuild all the dependent applications. An agile approach would try toencapsulate data dependencies to go fast and allow change. But ultimately relational dataissues will be important for agile projects and are a common blockage point. As such agileprojects are best suited where projects don't contain big legacy databases. It still isn't the endof the world because if you can build your data dependencies to be agile regardless of legacysystems you will start to prove the merit of the approach as all other systems go throughtedious changes to catch up with data changes while in the protected agile data system thechange would be trivial.

of 17 50405959.doc



Agile methods and method tailoring

In the literature, different terms refer to the notion of method adaptation, including ‘methodtailoring’, ‘method fragment adaptation’ and ‘situational method engineering’. Method tailoringis defined as:

A process or capability in which human agents through responsive changes in, and dynamicinterplays between contexts, intentions, and method fragments determine a systemdevelopment approach for a specific project situation.

Potentially, almost all agile methods are suitable for method tailoring. Even the DSDM methodis being used for this purpose and has been successfully tailored in a CMM context. Situation-appropriateness can be considered as a distinguishing characteristic between agile methods andtraditional software development methods, with the latter being relatively much more rigid andprescriptive. The practical implication is that agile methods allow project teams to adaptworking practices according to the needs of individual projects. Practices are concreteactivities and products which are part of a method framework. At a more extreme level, thephilosophy behind the method, consisting of a number of principles , could be adapted (Aydin,

2004).

In the case of XP the need for method adaptation is made explicit. One of the fundamentalideas of XP is that there is no process that fits every project as such, but rather practicesshould be tailored to the needs of individual projects. There are also no experience reports inwhich all the XP practices have been adopted. Instead, a partial adoption of XP practices, assuggested by Beck, has been reported on several occasions.

A distinction can be made between static method adaptation and dynamic methodadaptation . The key assumption behind static method adaptation is that the project context isgiven at the start of a project and remains fixed during project execution. The result is a staticdefinition of the project context. Given such a definition, route maps can be used in order todetermine which structured method fragments should be used for that particular project, basedon predefined sets of criteria. Dynamic method adaptation, in contrast, assumes that projectsare situated in an emergent context. An emergent context implies that a project has to dealwith emergent factors that affect relevant conditions but are not predictable. This also meansthat a project context is not fixed, but changing during project execution. In such a caseprescriptive route maps are not appropriate. The practical implication of dynamic methodadaptation is that project managers often have to modify structured fragments or eveninnovate new fragments, during the execution of a project (Aydin et al, 2005).

Agile Methods

Some of the well-known agile software development methods:

• Agile Modeling• Agile Unified Process (AUP)• Agile Data• Daily kickoff and review of goals• short release cycles• Responsive Development

of 17 50405959.doc



• Generalism - Use of generic skill sets which are common across the team not reliance onspecific skill sets which are scarce

• Test Driven Development (TDD)• Feature Driven Development (FDD)• Behavior Driven Development (BDD)• Essential Unified Process (EssUP)

Other approaches:

• Software Development Rhythms• Agile Documentation• ICONIX Process• Microsoft Solutions Framework (MSF)• Agile Data Method• Database refactoring

Measuring agility

While agility is seen by many as a means to an end, a number of approaches have beenproposed to quantify agility. Agility Index Measurements (AIM) score projects against a numberof agility factors to achieve a total. The similarly-named Agility Measurement Index, scoresdevelopments against five dimensions of a software project (duration, risk, novelty, effort, andinteraction). Other techniques are based on measurable goals. Another study using fuzzymathematics has suggested that project velocity can be used as a metric of agility.

While such approaches have been proposed to measure agility, the practical application of suchmetrics has yet to be seen.

Criticism

Agile development is sometimes criticized as cowboy coding. Extreme Programming's initialbuzz and controversial tenets, such as pair programming and continuous design, have attractedparticular criticism, such as McBreen and Boehm and Turner. Many of the criticisms, however,are believed by Agile practitioners to be misunderstandings of agile development.

In particular, Extreme Programming is reviewed and critiqued by Matt Stephens's and DougRosenberg's Extreme Programming Refactored .

Criticisms include:

• Lack of structure and necessary documentation• Only works with senior-level developers• Incorporates insufficient software design• Requires too much cultural change to adopt• Can lead to more difficult contractual negotiations• Can be very inefficient -- if the requirements for one area of code change through

various iterations, the same programming may need to be done several times over.

of 17 50405959.doc



Whereas if a plan was there to be followed, a single area of code is expected to bewritten once.

• Impossible to develop realistic estimates of work effort needed to provide a quote,because at the beginning of the project no one knows the entire scope/requirements

• Drastically increases the chances of scope creep due to the lack of detailed requirementsdocumentation

The criticisms regarding insufficient software design and lack of documentation are addressed

by the Agile Modeling method which can easily be tailored into agile processes such as XP.

Agile software development has been criticized because it will not bring about the claimedbenefits when programmers of average ability use this methodology, and most developmentteams are indeed likely to be made up of people with average (or below) skills.

Agile Principles

There are ten principles of Agile Testing:

Agile Principle #1: Active user involvement is imperative

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 externalcustomers or consumers.

In this event it is imperative to have a senior and experienced user representative involvedthroughout.

Not convinced? Here's 16 reasons why!

• 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 thanresorting to lengthy documents that aren't read or are misunderstood

• Emerging requirements can be factored into the development schedule as appropriatewith 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

of 17 50405959.doc



• 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 acustomer-supplier relationship but a joint team effort

• Timely decisions can be made, about features, priorities, issues, and when the product isready

• Responsibility is shared; the team is responsible together for delivery of the product

• Individuals are accountable, reporting for themselves in daily updates that involve theuser/business

• When the going gets tough, the whole team - business and technical - work together !

Agile Principle #2: Agile Development teams must be empowered

An Agile Development project team must include all the necessary team members to makedecisions, and make them on a timely basis.

Active user involvement is one of the key principles to enable this, so the user or userrepresentative 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 theirresponsibility to deliver the product and that they have complete ownership. Any interferencewith the project team is disruptive and reduces their motivation to deliver.

The team must establish and clarify the requirements together, prioritise them together, agreeto 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 toget a subset of the team to do this (maybe just the product owner and analyst), because it’smuch 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 veryexpensive way to do things.

However this is a key principle for me. It ensures the buy-in and commitment from the entireproject team from the outset; something that later pays dividends. When challenges arisethroughout the project, the team feels a real sense of ownership. And then it's doesn't seem soexpensive.

Agile Principle #3: Time waits for no man!

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 isto capture all known requirements and baseline the scope so that any other changes aresubject to change control.

Traditionally, users are educated that it’s much more expensive to change or add requirements

of 17 50405959.doc



during or after the software is built. Some organisations quote some impressive statisticsdesigned 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 what’s more, it’s allimportant for the first release, because we all know Phase 2’s are invariably hard to getapproved 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 aslow 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 thinkof everything, things change, and things are understood differently by different people.

Agile Development works on a completely different premise. Agile Development works on thepremise that requirements emerge and evolve, and that however much analysis and design youdo, this will always be the case because you cannot really know for sure what you want untilyou see and use the software. And in the time you would have spent analysing and reviewingrequirements 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 theoutset when the requirements are written – it’s inherently difficult, perhaps even practicallyimpossible, to build the right solution using a traditional approach to software development.

Traditional projects fight change, with change control processes designed to minimise and resistchange wherever possible. By contrast, Agile Development projects accept change; in fact theyexpect it. Because the only thing that’s 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 toinclude a new requirement, or to change a requirement, the user or product owner mustremove 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 toevolve into the right solution. It does, however, also pre-suppose that there’s enough non-mandatory features included in the original timeframes to allow these trade-off decisions tooccur without fundamentally compromising the end product.

So what does the business expect from its development teams? Deliver the agreed businessrequirements, on time and within budget, and of course to an acceptable quality. All softwaredevelopment professionals will be well aware that you cannot realistically fix all of these factorsand expect to meet expectations. Something must be variable in order for the project tosucceed. In Agile Development, it is always the scope (or features of the product) that arevariable, not the cost and timescale.

Although the scope of an Agile Development project is variable, it is acknowledged that only afraction of any product is really used by its users and therefore that not all features of a productare really essential. For this philosophy to work, it’s imperative to start development

(dependencies permitting) with the core, highest priority features, making sure they aredelivered in the earliest iterations.

Unlike most traditional software development projects, the result is that the business has afixed budget, based on the resources it can afford to invest in the project, and can make plansbased on a launch date that is certain.

Agile Principle #4: Agile requirements are barely sufficient!

of 17 50405959.doc



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 minimumrequired to enable development and testing to proceed with reasonable efficiency. The rationalefor this is to minimise the time spent on anything that doesn’t actually form part of the endproduct.

Agile Development can be mistaken by some as meaning there’s no process; you just makethings 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 developmentmethodologies, Agile Development does nevertheless have quite a bit of rigour and is based onthe fairly structured approach of lean manufacturing as pioneered by Toyota.

However any requirements captured at the outset should be captured at a high level and in avisual 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 andproduce 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 requirementsas well as each other. It is not necessarily the remit of one person, like the Business Analyst inmore 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 understandwhat’s needed. And just as importantly, why.

XP (eXtreme Programming) breaks requirements down into small bite-size pieces called UserStories. These are fundamentally similar to Use Cases but are lightweight and more simplistic intheir 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 andhow the user’s interaction will flow in the solution. There is no lengthy requirements documentor specification unless there is an area of complexity that really warrants it. Otherwise thestoryboards are just annotated and only where necessary.

A common approach amongst Agile Development teams is to represent each requirement, usecase or user story, on a card and use a T-card system to allow stories to be moved aroundeasily 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 it’s going on a card forces it to be broken down small. The advantage this has over lengthydocumentation is that it's extremely visual and tangible; you can stand around the T-cardsystem and whiteboard discussing progress, issues and priorities.

The timeframe of an Agile Development is fixed, whereas the features are variable. Should it benecessary to change priority or add new requirements into the project, the user/businessrepresentative physically has to remove a comparable amount of work from scope before theycan place the new card into the project.

This is a big contrast to a common situation where the business owner sends numerous newand changed requirements by email and/or verbally, somehow expecting the new and existing

of 17 50405959.doc



features to still be delivered in the original timeframes. Traditional project teams that don'tcontrol changes can end up with the dreaded scope creep, one of the most common reasons forsoftware development projects to fail.

Agile teams, by contrast, accept change; in fact they expect it. But they manage change byfixing 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 afeature to be developed, and always broken down into very small units.

Using the Scrum agile management practice, requirements (or features or stories, whateverlanguage you prefer to use) are broken down into tasks of no more than 16 hours (i.e. 2working days) and preferably no more than 8 hours, so progress can be measured objectivelyon a daily basis.

Agile Principle #5: How d'you eat an elephant?One bite at a time ! Likewise, agile software 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 developingall 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; andso on... doing each step for each feature, one feature at a time.

Advantages of this iterative approach to software development include:

• Reduced risk: clear visibility of what's completed to date throughout a project

• Increased value: delivering some benefits early; being able to release the productwhenever it's deemed good enough, rather than having to wait for all intended featuresto be ready

• More flexibility/agility: can choose to change direction or adapt the next iterationsbased on actually seeing and using the software

• Better cost management: if, like all-too-many software development projects, yourun over budget, some value can still be realised; you don't have to scrap the wholething if you run short of funds

For this approach to be practical, each feature must be fully developed, to the extent that it'sready to be shipped, before moving on.

Another practicality is to make sure features are developed in * priority * order, not necessarilyin a logical order by function. Otherwise you could run out of time, having built some of the lessimportant features - as in agile software development, the timescales are fixed.

of 17 50405959.doc

http://www.onestoptesting.com/agile-testing/principle-five.asp








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, andonly then move on to the could-haves. Otherwise you can get into a situation where yourearlier features are functionally rich, whereas later features of the software are increasingly lesssophisticated 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

Agile Principle #6: Fast but not so furious!

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

Nowhere is this more true than on the web . The web is a fast moving place. And with theluxury of centrally hosted solutions, there's every opportunity to break what would have

traditionally been a project into a list of features, and deliver incrementally on a very regularbasis - ideally even feature by feature.

On the web, it's increasingly accepted for products to be released early (when they're basic, notwhen they're faulty!). Particularly in the Web 2.0 world, it's a kind of perpetual beta. In thissituation, why wouldn't you want to derive some benefits early ? Why wouldn't you want tohear real user/customer feedback before you build 'everything'? Why wouldn't you want to lookat 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 agiledevelopment . 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-12months+, 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 software is just too large tobe practical on such a regular basis.

Agile Principle #7: "done" means "DONE!"

In agile development, "done" should really mean "DONE!" .

Features developed within an iteration (Sprint in Scrum), should be 100% complete by the endof the Sprint.

Too often in software development, "done" doesn't really mean "DONE!". It doesn't meantested. It doesn't necessarily mean styled. And it certainly doesn't usually mean accepted bythe product owner. It just means developed.

of 17 50405959.doc



In an ideal situation, each iteration or Sprint should lead to a release of the product. Certainlythat's the case on BAU (Business As Usual) changes to existing products. On projects it's notfeasible to do a release after every Sprint, however completing each feature in turnenables a very precise view of progress and how far complete the overall project really isor isn't.

So, in agile development , make sure that each feature is fully developed, tested, styled, andaccepted 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 beshipped. But the feature on its own merit should be shippable. So if you're ever unsure if afeature 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 workof each developer, do not move on to a new feature until the last one is shippable. This isimportant to ensure the overall product is in a shippable state at the end of the Sprint , notin a state where multiple features are 90% complete or untested, as is more usual in traditionaldevelopment projects.

In agile development , "done" really should mean "DONE!" .

Agile Principle #8: Enough's 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 * 80% of your results may actually come from only 20% of your efforts!

areto's law can be seen in many situations - not literally 80/20 but certainly the principle thatthe 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/20rule , 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 whyyou would ever bother doing the last 20%?

that doesn't mean your product should be fundamentally flawed, a bad userexperience, 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 beworthwhile.

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 tobe 100% complete within the iteration.Agile Principle #9: Agile testing is not for dummies!

of 17 50405959.doc



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

Agile development does not have a separate test phase as such. Developers are much moreheavily 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 supportthe 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, atleast daily, so integration is done as you go too .

The purpose of these principles is to keep the software in releasable condition throughout thedevelopment, so it can be shipped whenever it's appropriate.

The XPeXtreme Programming) agile methodology goes further still. XP recommends testdriven development , writing tests before writing the software .

But testing shouldn't only be done by developers throughout the development. There is still avery important role for professional testers, as we all know "developers can't test fortoffee!" :-)

The role of a tester can change considerably in agile development , into a role more akin toquality assurance than purely testing. There are considerable advantages having testersinvolved from the outset<.

This is compounded further by the lightweight approach to requirements in agiledevelopment , and the emphasis on conversation and collaboration to clarify requirementsmore than the traditional approach of specifications and documentation.

Although requirements can be clarified in some detail in agile development (as long as theyare done just-in-time and not all up-front), it is quite possible for this to result in someambiguity 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 anagile development approach - particularly from those moving from a much more formalenvironment - is that they don't know precisely what they're testing for. They don't have adetailed spec to test against, so how can they possibly test it?

Even in a more traditional development environment, I always argued that testers could testthat software meets a spec, and yet the product could still be poor quality , maybe becausethe requirement was poorly specified or because it was clearly written but just not a very goodidea 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 areonly really evident when the software can be seen running. By delivering small incrementalreleases and by measuring progress only by working software, the acid test is seeing thesoftware 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 moreexpertise about what's good and what's not, the ability to be more flexible and having theconfidence 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.

of 17 50405959.doc



And for these reasons, agile testing is not for dummies!

Agile Principle #10: No place for snipers!

Agile development relies on close cooperation and collaboration between all teammembers 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-timeand to keep all team members (including the product owner) 'on the same page' throughoutthe development.

You certainly can't do away with a big spec up-front * and * not have closecollaboration . You need one of them that's for sure. And for so many situations the latter canbe more effective and is so much more rewarding for all involved!

In situations where there is or has been tension between the development team andbusiness people , bringing everyone close in an agile development approach is akin to aboxer 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 , creatingbetter teamwork, fostering team spirit, and building stronger, more cooperative relationships.

There are many reasons to consider the adoption of agile development , and in the nearfuture I'm going to outline "10 good reasons to go agile" and explain some of the keybusiness benefits of an agile approach .

If business engagement is an issue for you, that's one good reason to go agile you shouldn'tignore.

of 17 50405959 doc

One Stop Agile software development explained

Documents

Transcript of One Stop Agile software development explained