Академический Документы
Профессиональный Документы
Культура Документы
Transition
from
Waterfall to Agile
Gallop proprietary and condential. Not for public distribution | www.gallop.net
|1
Abstract
In his article 'Tradeos: Giving up Certainty', Paul
Dolman-Darrall explored the trade-os companies typically
face when contemplating a shift from conventional waterfall-based methods to more agile approaches. As the
author rightly concludes, eective progress on this
journey often emerges from trial and error, plus ne
tuning of methods found to be eective. This is the case
with most forms of innovation, as Darwin observed. If you
dig deep into the IT department of any large organisation,
you will nd many examples of successful adoption of agile
delivery practices even if the organisation itself remains
heavily waterfall-centric. These pockets of innovation
typically emerge through bottom up endeavors usually
instigated by focused individuals or small teams that are
quick to see the local benet oered by such practices.
Company leaders have traditionally been unconcerned with
the nuts and bolts of their internal software development
eorts, but the recent challenges facing some high-prole
projects have placed these issues at the forefront of
business concerns. Hybrid agile things are often not a
good idea. They just create confusion and sometimes
extra non-value producing work. The risk is that people
cherry pick practices from dierent methods and use the
introduction of agile as an excuse not to exercise
discipline in how they operate. The second risk is that a
half-hearted adoption of agile has a great possibility of
poisoning the well for a later successful adoption.
There is already some signicant factor holding back the
adoption of agile; those naysayers will point to the
weaknesses in the half adoption as reasons why it is not
a good idea to begin with. Then it makes a subsequent
decision for this team to adopt an agile method like scrum
even more problematic. It is becoming increasingly
dicult for companies to compete successfully when their
initiatives or product improvements take many months or
even years to bring to fruition. Nimble, rapidly adapting
organizations are thriving, winning market share. They
make it a priority for everyone to nd ways to delight their
customers, while nding joy in work for people.
Slow-changing businesses that fail to engage eectively
the intelligence and passion of all their people, see their
livelihood erode and sometimes even vanish altogether.
To further complicate matters, the predominant ways in
which many executives still think, structure, and run their
organizations, work against the speed of adaptation,
despite their best intentions to the contrary.
2.1
Waterfall Models
|2
2.2
2.3
SCRUM
|3
|4
There is no such thing as an agile tool. Also the Agile Manifesto and Principles are guidelines, really good guidelines
based on practical experiences that has proven to work,
and should be treated as such.
The values on the left are more important than on the
right. These values compensate for the shortcomings of
the The Agile Software Development Methods have the
potential to provide higher customer satisfaction, lower
bug rates, shorter development cycles, and quicker
adaptation to rapidly changing business requirements.
Scrum is a framework to organize people and deliver a
quality product on time. Scrum is not a process or a
technique for building products; rather, it is a framework
within which you can employ various processes and
techniques.
2.4
SCRUM TEAM
---------- ----------------------
----------------------------- -
Implementation
Analysis
-----------------------------
Testing
|5
---------------------
2.4.1. Events
---------- -----------------
---------------------------
|6
2.4.2. Artifacts
Scrums artifacts represent work or value to provide
transparency and opportunities for inspection and
adaptation. Artifacts dened by Scrum are specically
designed to maximize transparency of key information so
that everybody has the same understanding of the
artifact.
----------------------
---------- -----------------
---Product
--- ---The
-----Increment is the sum of all items completed
- and- the previous Sprints. The new increduring the Sprint---- condition and must meet the
ment must be in useable
-- -denition of done.
The Product Backlog is an ordered list of functionality
The Denition of Done is a description of when a Backlog
Item can be considered done and is dierent per Development Team. They have a shared understanding of when
work is complete to ensure transparency .
According to case-study research in ve companies the
conclusion was that SCRUM works in any environment
and can scale into programming in the large. Scrum can
result in a high productivity increase in comparison with
traditional methods.
Another advantage: Scrum cuts through project complexity
and brings order from chaos by enabling a team to organize itself, which allows a particularly productive order to
emerge.
---------------------------
|7
2.6 Hybrid
Another disadvantage of Scrum is the uncertainty. There
are two competing priorities: the need for certainty by
following rigid and formal engineering processes, and the
need to remain agile to deal with drift in requirements and
uncertainty.
------------------
-------------------------------------------Testing
Deploy
--------
Coding
Design
--------
--------
Transition Challenges
------------------
--------------------
--------
2.7
Analysis
--------
Requirements
----------------------------------------------------Requirements
--------
------------------
End
-------------------------------------------
|8
Managers are used to command and control. Team members in Scrum are able to gure out how to do their work,
if they get instructions they arent free to do their work
the best way possible. This is a signicant change in the
manager role. This problem of the Scrum Master
controlling and pushing instead of letting the team organize itself is also stated in.
|9
This can cause the team to be less optimistic and fall back
to old Waterfall methods to meet the deadlines. Another
important factor is feedback inside the team. Team
members need to give continuous feedback to each other
so they can improve their way of working. This requires
openness and transparency. Often problems are not
reported because team-members perceive the problem as
personal. Another reason is lack of trust in the team or
Scrum Master. Also, if problems are not handled, the team
could stop reporting them. This continuous learning
process takes time and if work pressure is high this has a
negative impact on learning.
2.7.5 Productivity
Each Sprint in Scrum is 2 to 4 weeks. During this sprint, the
teams should stick to the Sprint backlog. Only in exceptional
cases (when productivity is not aected) work can be
added to the backlog. During sprints there is a total
inexibility in what to work on, during the planning
meeting backlogs are added and the Sprint backlog is
xed. This sometimes causes a perception of inexibility,
because direction cannot be changed immediately.
Managers thus could be sceptic about this inexible way
of working during sprints, but it is one of the most
important constraints of Scrum. Not respecting this will
cause a drop in productivity. Measurements of productivity
should be carefully chosen, it inuences the way people
work.
Over-commitment is a bad habit. If someone is pressured
to commit to an outcome that is not realistic, this can
cause serious problems in productivity. Work pressure is
high and quality might be at risk. On the other side, if
maintenance and bug xing is taking too much time the
productivity might also be at risk.
| 10
| 11
References
1. Challenges in the Transition from Waterfall to Scrum a Case study at Port base
http://referaat.cs.utwente.nl/conference/20/paper/7427/challenges-in-the-tansition-fromwaterfall-to-scrum-a-casestudy-at- portbase.pdf
2. The Corporate Agile Journey A Practical Viewpoint
http://www.infoq.com/articles/corporate-agile-journey
3. How to transit from waterfall to Agile- Amit Malik Blog
http://amitsinghmalik.blogspot.in/2012/07/how-to-transition- from-waterfall-to.html
4. Accredited Scrum Master (ASM) - Agile Certication ACI ASM handbook
5. Blog Agile / Scrum Making the successful transition to Agile development - Making the successful transition to Agile
development. By Tom Helvick
6. Agile Journey - Steps along the way to Being Agile"- http://agileadventure.blogspot.in/
7. Scrum (Software Development) http://en.wikipedia.org/wiki/Scrum_%28software_development%29
About Gallop
Gallop Solutions is a US based Colocated Independent Testing Services & Specialist QA Stang Services Company operating
since 2003 with oces in Philadelphia & California. Our services are backed by Proprietary Testing IP (Enterprise Test Acceleration Suite - ETAS) for enhanced productivity and in-house R&D teams. We are a 100% subsidiary of Cigniti Technologies,
World's 3rd largest independent software testing services company with over 1600 consultants globally across various
domains with 400 located in North America.
Gallop constantly innovates and invests in R&D around software testing and contributes immensely to the software testing
community by thought leadership blogs, articles and whitepapers. World's largest and leading organizations have relied on
Gallop's specialist independent software testing services for more than a decade and have achieved signicant market acceleration, returns on investments in their software quality initiatives.