Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« Striking the Balance: Waterfall and Agile - Part 2 | Main | Are our agile estimates really bad? »

Striking the Balance: Waterfall and Agile - Part 3

In part 1 of this blog series, we discussed on how business and application related considerations affect selection of SDLC methodology

In Part 2 of this blog series  we saw impact of agile team execution location as well as what pre requisites are considered while team is formed for execution, paving way for inclination to type of methodology preferred.

In this blog post, we will continue to explore information on organizations exiting situation around organization's current/proposed technologies/ tools repository and automation; it's future investment roadmap. This will help driving out methodology choices.

Agile approach requires collaboration and communication among team members either in collocated or distributed situation. Tools and Technologies providing effective communication such as conference call , video conferencing facilities, polyphones, emails, instant messaging, web cameras, video calling, WebEx, On Sync, Chat as well as enterprise agile lifecycle management tools, Wikies, SharePoint sites, Blogs should be made available, particularly in the case of distributed teams. If team is following phase gate waterfall work, good project management system with time/task tracking and monitoring, knowledge/document management systems are required.

Agile advocates shorter release cycles necessitating regular and frequent check-ins and check-outs by teams. Agile advises use of fast and reliable source code repository solution that can be easily accessed by distributed teams. Waterfall approach desires a source code repository system.

Agile assures working software at the end of each sprint. To enable development in short cycles and to sustain good quality and high velocity, the team should be able to quickly and effectively test what it develops. Following practices such as test-first approach like TDD, acceptance test driven development (ATDD), behavior driven Development (BDD) and creating a robust set of automated tests after team reaches certain maturity, helps maintain system health after multiple sprints without impacting speed of delivery. While this involves significant adoption effort and behavioral changes like pair programming, these yield better outcomes over a period of time.
On the other hand, Test-first approaches and pair programming seems impractical in waterfall approach, Test automation is desirable, provided it meets the constraints of cost and resources as testing is a phase and there is no pressure to deliver in a time boxed manner.

Agile project expects continuous integration involving regular and automated build, integration and testing of software being followed to inspect/adapt with faster feedback cycles delivering better results. This is advised to be considered as early as possible during release cycle, may be form iteration 1 itself.
This needs to be analyzed within constraints of cost and resources during waterfall, may be during integration phase. 

Agile advises dedicated development and quality assurance (QA) environments for agile teams along with enough hardware, software licenses, and IT support staff to build or maintain those environments as working software is getting delivered in short time box of few weeks iterations.
Infrastructure, IT asset management teams as well as operations teams needs to work collaboratively with agile teams to support multiple dev./test environments, servers, databases, networks, and other third party softwares.
Waterfall approach if taken and organization mandates certain cost and resource constraints, above mentioned resource requirements needs to be well planned in advance to make these available during development/ test phase.

Pre requites for agile implementation is better communication and collaboration technology along with adequate automation wherever possible; demands investments upfront, with possibility of returns only in the long run.

It also demands leadership backing with long term vision and investment appetite, mind shift change of teams with changing roles & responsibilities due to initiatives like automation and collaboration. Many organization in search of resources will keep working in business as usual mode.

In the last of this blog post series, we will discuss on how projects and programs dependencies affect quest to reach final stages of methodology approach selection.


Nice post. Got to learn few things

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.