June 2012

Shift your Software delivery into high gear with agile

Shift your Software delivery into high gear with agile >
todays 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 eective software on time is simply not an option.

TRADITIONAL SOFTWARE DEVELOPMENT PROJECT SUCCESS RATE

21%

successful failed chalenged

42%

37%
Source: Standish Group's 2011 CHAOS Report Source: Standish Group's CHAOS Report

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 classied either as challenged or as complete failures, with only 37 percent classied as successful. its 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 systems 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 eective and increasingly obsolete in todays fast-paced business setting. we see several problems with the assumption-based and reductionism approaches practiced in traditional waterfall software development:

02

luxoft Shift your software delivery into high gear with agile

waSte of money >

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

high CoStS of Change >

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 eort 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, inexible and costly change cycles.

wrong featureS prioritization >

with an overwhelming planning stage, traditional software development models dont 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 aects the software quality as well. without the correct understanding of all the systems viable features and priorities, there is a greater chance that its architecture might not be developed correctly and that any changes will be more dicult and costlier to implement.

03

luxoft Shift your software delivery into high gear with agile

laCk of proJeCt tranSparenCy >

at rst glance, the waterfall methodology reporting structure seems to be a well-dened process. numerous status reports and progress metrics promise full transparency and control over the project. however, this rst 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.

high SyStem Complexity and BatCh delayS >

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 systems 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 exibility. more importantly, agile avoids most of the assumptions of the waterfall model, helping companies better manage risks, increase exibility, 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 aws of the waterfall methodology:

BuSineSS value driven prioritization >

in agile projects, system functionality is prioritized and delivered according to business value, enabling faster realization of desired benets.

paying for done >

developed functionality is demonstrated to the client through regular delivery iterations (every 15 - 30 days) and is accepted only if it meets the denition of done .

04

luxoft Shift your software delivery into high gear with agile