shift your software delivery into high gear with agile
Post on 03-Feb-2022
4 Views
Preview:
TRANSCRIPT
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
top related