June 2012

Shift your Software delivery into highgear with agile

Shift your Software delivery into high gear with agile

–> today’s business environment is growing exponentially more complex as companies face

increasingly greater pressure to respond quickly to shifting marketplace dynamics, to innovate

for the future, and to provide consistent value. Business demand for it is stronger than ever

and expectations have become much more sophisticated. Clients are already overburdened

by cumbersome, unresponsive technology, so failure to deliver effective software on time is

simply not an option.

yet, software development projects continue to fail at an alarming rate. the Standish group's

2011 ChaoS report found that more than 50 percent of all software projects conducted

between 2002 and 2010 were classified either as challenged or as complete failures, with only

37 percent classified as successful. it’s no surprise then, that software development is often

viewed as a risky and costly venture.

the root cause of this problem is in the use of predictive software development processes in

complex, unpredictable and sometimes even chaotic business environments. the majority

of projects today are still using the traditional waterfall planning methodology, which is best

suited for predictable, repeatable work. years of project work is developed based on

assumptions and past experiences.

the reductionism approach, which is often used to explain and predict a system’s behavior

by reducing it to the interactions of its parts, or to simpler rudimentary units, is still practiced

in many classical hierarchical team structures and management techniques. these types of

traditional project planning and management methods are becoming less effective and

increasingly obsolete in today’s fast-paced business setting.

we see several problems with the assumption-based and reductionism approaches practiced

in traditional waterfall software development:

TRADITIONAL SOFTWARE DEVELOPMENT PROJECT SUCCESS RATE

successful

Source: Standish Group's 2011 CHAOS ReportourS 's 2011 CHAouptandish Gre: Scour teporOS R's 2011 CHA

failed

chalenged

42% 37%

21%

luxoft – Shift your software delivery into high gear with agile02

the traditional “waterfall” software development methodology calls for the entire system

design upfront. it is based on the assumption that one knows the entire system functionality

and can plan for it at once. however, that is hardly possible in today’s world of rapidly

changing priorities, trends and context. in addition, traditional change management is too

cumbersome and inert to address changes mid-cycle. as a result, companies are often left

with engagements that focus on the project plan execution, rather than developing

functionality according to the latest business priorities and feedback from early system users.

this, in turn, leads to budgets being spent on features that are rarely if ever needed by the

end users.

Complex project plans, loads of upfront documentation, burdensome document-based

review and approval processes, and upfront architecture design; all these parts of traditional

waterfall development-based projects result in an enormous effort to release a system

(manual build/deployment procedures) and ensure its quality (longer test cycles due to

manual testing). as a result, Cios are frequently left with long, inflexible and costly change

cycles.

with an overwhelming planning stage, traditional software development models don’t

account for the software demonstration to end-users until three to six months into the project.

additionally, engineers often tend to start the development process with its more appealing

technical parts, such as architecture, frameworks, base classes, and libraries, steering away

from core business features development.

as a result, business users are frequently unable to see the functioning system prototype until

six months into the project, which is far too long for those to whom time-to-market is of

utmost importance. lack of timely evaluation and feedback from end users affects the

software quality as well. without the correct understanding of all the system’s viable features

and priorities, there is a greater chance that its architecture might not be developed correctly

and that any changes will be more difficult and costlier to implement.

waSte of money

–>

–>high CoStS of Change

wrong featureS prioritization

–>

luxoft – Shift your software delivery into high gear with agile03

at first glance, the waterfall methodology reporting structure seems to be a well-defined

process. numerous status reports and progress metrics promise full transparency and control

over the project. however, this first impression is often a deceiving one. in most cases, real

project status is hindered by unnecessary paperwork and overly formal process-oriented

relationships. Being unable to physically “go see” the system, try its features, and provide

feedback regularly may add to the frustration.

long-term, up-front planning and high cost of change create numerous dependencies,

making it impossible to test the system quickly. this, in turn, increases the system’s complexity

and leads to batch delays.

the holistic approach and systemic thinking that make up the foundation of agile project

development are gaining additional traction as they are quickly becoming main drivers of

successful and predictable software development initiatives. more companies are turning to

agile development because it proactively addresses core reasons for project failures,

delivering greater transparency and flexibility. more importantly, agile avoids most of the

assumptions of the waterfall model, helping companies better manage risks, increase

flexibility, react faster to business opportunities, and stay ahead of the competition by

meeting the ever-changing needs of their customers.

the agile method of development has several winning practices that directly address flaws

of the waterfall methodology:

in agile projects, system functionality is prioritized and delivered according to business value,

enabling faster realization of desired benefits.

developed functionality is demonstrated to the client through regular delivery iterations

(every 15 - 30 days) and is accepted only if it meets the definition of “done “.

–>

–>

–>

laCk of proJeCt tranSparenCy

high SyStem Complexity and BatCh delayS

BuSineSS value driven prioritization

paying for “done”

–>

luxoft – Shift your software delivery into high gear with agile04