June 2012
Shift your Software delivery into high gear 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.
TRADITIONAL SOFTWARE DEVELOPMENT PROJECT SUCCESS RATE
21%
successful failed chalenged
42%
37% SSource: ource: SStandish tandish Gr Group's oup's 2011 CHA CHAOS OS Report 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 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:
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 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.
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 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.
wrong featureS prioritization –>
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.
03
luxoft – Shift your software delivery into high gear with agile
laCk of proJeCt tranSparenCy –>
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.
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 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:
BuSineSS value driven prioritization –>
in agile projects, system functionality is prioritized and delivered according to business value, enabling faster realization of desired benefits.
paying for “done” –>
04
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 “.
luxoft – Shift your software delivery into high gear with agile