Transitioning from Waterfall to Agile: Tips for a Smooth Journey
Sanjay Zalavadia explores the key concepts behind a smooth and successful transition from Waterfall to Agile practices.
Join the DZone community and get the full member experience.Join For Free
excitement over agile methodologies has exploded since 2010. echoes of a near panacea in software delivery have extolled agile techniques as the solution to customer demands on application interface. clarity of application is the primary attribute that many agile teams and companies acclaim.
agile methodology clarifies software delivery and facilitates the delivery pipeline. however, smooth transition to agile is more opaque in its complexity. the organic nature of agile drills beyond procedure more deeply into the essence of vision and development. the challenge of transition from procedure-driven tradition to organically-driven innovation is a near-total shift in conceptual stature. to begin the journey, let’s first look at the point from where software development has emerged.
what is waterfall?
the traditional approach to system design and development has been waterfall. waterfall, so named because development and release follows a descending set of chronological steps, requires that all processes consistently flow from project beginning to project end. the sequential stages of requirements, design, implementation, verification, and maintenance consistently remain in place. the waterfall method assumes that all elements of development are to be assembled at the beginning of a project. user input, managerial needs, and anticipated outcomes are decided before the project is actually implemented. then the rest of the project is enacted in a subsequent flow as in a waterfall.
the waterfall approach is very structured according to defined procedures. waterfall testing is conducted by reference to requirements-defined functions and design-defined scenarios formulated in the initial stages of the project. the structured approach to delivery often depends on abstract client-defined requirements, a fact that often compels re-engineering of the full application during the verification stage. as requirements rapidly change the original requirement and design may no longer apply to consumer needs or preference. and because the project is sequential, it tends to require a longer production timeline.
the pattern of waterfall design is sequential rather than iterative. the project flows in a descending order of stages that better applies to physical manufacturing and construction than virtual coding design. development is based on irreversibly constructed divisions. although feedback loops between phases allow for modification, the process elongates time to market. modification generally only allows updating the immediately previous phase and does not generally take into account how updates may alter the validity of other phases of development. the extended time required for unanticipated updates makes for inaccurate time and cost estimates.
with a near 60% failure of the waterfall method to deliver , the need for initially stable software, for agility rather than finite structure, iteration rather than strictly formatted stages, updating outdated findings in iterative implements, and re-defining done, motivated systems analysts search for an alternate means of software delivery.
image source: douglas a. hughey
what is agile?
agile is more than a buzzword. development with agile is iterative and incremental in its approach to software development. the outcomes of earlier stages in development impact or determine the planning of subsequent stages. agile is an answer to the challenges of software development and release that is apart from the strictly controlled waterfall model.
agile approaches software development from an innovative perspective. techniques based on predictable results are eradicated from agile methodology. agile processes not only accept the uncertainties of the software build, they utilize uncertainty as a resource for innovation. preconceived expectations are foreign to the organic nature and incremental technique of the agile build.
the non-hierarchical agile approach enables teams and team members to freely collaborate within self-directed teams. teams initiate development with succinct descriptions of build components and formulate details through iterative increments of development, discussion, testing, and review. risks are better managed through incremental means of product engineering. incremental development also more quickly produces functional software applications. testing and review are also incremental, occurring throughout the development process rather than at the culmination of production. management and project sponsors can make resolute decisions along the development timeline.
image source: forty
agile is designed to promote positive and functioning relationships among team members, enabling self-administered teams and team processes that address the continual consumer demand for updates and the fluctuating levels of software consumption. teams integrate multi-talented resources into cross-functional process to boost production and inspire innovation.
agile methodologies allow assessment of project direction throughout the entire software lifecycle. the strategy of regular iterations incentivize teams to produce potentially shippable output at the end of each incremental build, providing immediate opportunities to redirect objectives for quicker and more continuous delivery. in this way, software development can happen while requirements and analysis are occurring. development is integrated into fact-finding through the build activity rather than strictly defined as stages of production.
- collaborative interactions among individuals over processes and tools
- software development over extensive documentation
- interaction and collaboration with customers over contract negotiation
- responding to change over following the prescribed plan
the imperative attributes of agile development are:
- active user involvement
- teams empowered in decision-making
- requirements that are fluid while timelines are fixed
- envisioned as overall requirements at a high level
- executed as small, incremental release cycles that are iterative
- focus on frequent delivery
- assurance that each increment is done before moving on to the next incremental cycle
- ensuring that the testing lifecycle is integrated throughout the entire project lifecycle
- collaboration and cooperation among all stakeholders
the visual focus and collaborative participation of agile can be a rich and rewarding team experience that inspires the output of value in software applications. when team members are motivated, the results in production can be amazing.
transitioning to agile methodologies
hierarchical structures, such as the waterfall model, use leadership and power personality tools. leadership personalities employ salesmanship, are charismatic, use role modeling, and negotiate to effect process. power personalities also use negotiation and tend to finitely define roles, require authoritative permission, and sometimes use intimidation or coercion to influence production processes.
agile methodologies rely more on culture and the utilization of the right tools, including test management . agile emphasizes the culture of oral and plausible communication, belief and reverence for vision, prescribed forms of conduct, and people as the primary source of productive power. agile processes emphasize strategic planning, financial incentives, solid metrics, progressive standards, and self-motivation.
with these attributes in mind, transitioning from a traditional development model to agile development requires an approach that coincides with all points of organizational concern. the priority of those responsible for transitioning to agile should be to address each consideration that could be impacted by the transition, employing tools towards probable smooth operations during the transition process.
it is the responsibility of transition managers to ensure that agile techniques are applied to a project that suits agile processes. the project requires an active and engaged customer as a business sponsor. development should be of medium simplicity and have a timeline of 2-3 months. too much complexity that would complicate the learning process for team members should be avoided. and a shorter timeline can better engage management interest, which could otherwise wane over time. to further engage management, the initial agile project should be important to the organization, and one that would probably fail in meeting production and timeline requirements if it were developed within the waterfall model.
build the right team – select the right people
for the first agile project, begin with one agile team at project start, and expand to no more than five development teams during the project lifecycle. agile teams are multi-disciplinary. select the multi-talented people who may function productively on a cross-functional team. select team members whose thinking varies from the strict status quo, along with those who have varied backgrounds – such as an analyst with a philosophy degree.
avoid large egos, which tend to suck the air out of the room and also tend to lack self-evaluation. ensure that there are no negative relationships among team members. and do not force reluctant participation, even if from high expertise or political clout. enthusiasm is what promotes agile.
many times the best agile personalities are originators who may seem unorganized and unconventional. originators prefer change that challenges the current structure, which makes them probable inspired innovators. the originator personality challenges assumptions, thrives on risk and uncertainty, and demonstrates a reduced regard for policy. the drawbacks could be that the originator as a team member may be excessive, aggressive, and a renegade.
another personality to consider for an agile team is the pragmatist, who can be practical, agreeable, and flexible. the pragmatist prefers workable outcomes and is many times primarily focused more on results than structure. pragmatists tend to consider both sides of a matter and therefore can be effective mediators, while also gravitating more towards interaction with the team. drawbacks with the pragmatist may be indecisiveness and being overly compliant.
select team members that therefore complement each other’s personalities as well as each other’s technical expertise. also seek sponsors and opinion leaders who favor agile, visionaries who focus on innovation, and agents who have agile experience. a range of talents and perspectives make up the most innovative and productive agile teams.
acquire a buy-in from management
encourage and engage management into accepting and promoting transition goals. promote the cost-effective aspects of the agile process, as well as the speed to continuous delivery. overcome resistance to the as yet non-validated status of the project with attention to reduced risk. understand the traditional views that favor predictable behavior and continuous anticipation, so that you can emphasize and clarify the improved benefits of the iterative process in providing reliable outcomes.
understand that those who are most resistant to change are generally deliberate in their approach to situations, disciplined in their adherence to standards, and organized in their approach to processes. they normally prefer activities that preserve the status quo such as predictability, detail, and routine nurture their feeling of safety, which makes them cautious in respect to the unpredictable culture of the agile methodology.
first research who people in the organization listen to. these may not be those with formal authority. but they will be those who influence and advise operational behavior. convince the influencers of the benefits of agile. then utilize these influencers to convince decision makers. emphasize the problem that requires corrective action rather than any devised solution. people feel they already know the solutions. but fuller comprehension of the problem can lead to an understanding that solutions may be elusive and require the in-depth iteration of agile methodologies.
listen to alternative solutions and interject the manner in which agile methods parallel or interact with those solutions. then communicate why the change is currently necessary. let stakeholders know why now is the moment to invest in the agile process. help those who resist the transition see the development process and thereby recognize the benefits of the change into agile. then motivate their recognition with specific benefits that nurture their professional vested interests and alleviate their anxiety toward risk.
inspire the team
implant a sense of project urgency into the team. the importance of the project must be in the forefront of every team member’s motivation. then connect the team to a vision for the product and the process of delivery. the inspired vision of production is what inspires innovation and sees the team through difficult iterations. empower team members and the team as a whole to be decision makers within the process, and to act on their decisions.
image source: zen.digital
consolidate development into finely tuned team symmetry. utilize coaches experienced in agile methods to assist in synthesizing team performance. plan the build, support the process, and create incremental wins that produce conceptually deliverable products. plan, produce, test, adapt, and repeat.
agile as an alternative is proving to be a substantially feasible answer to software delivery.
Published at DZone with permission of Sanjay Zalavadia, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.