Many organizations have been using traditional software methodologies like the Waterfall model of software development,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Software Development Lifecycle (SDLC) and others, sometimes for decades. Switching these development groups from these methodologies to Agile development is easier said than done. Agile methodologies have their own advantages, but sometimes they lack some of the characteristics of traditional software development methodologies that are crucial for success. A hybrid solution may be the right answer sometimes for these organizations, rather than a pure Agile approach. Here are some of the reasons why pure Agile may not be suitable for some organizations and why a hybrid solution may be the right choice:
- Project and problem do not fit Agile methodology: Agile methodologies assume that most requirements can be broken up into features, further down into stories and scheduled for builds and releases. In large projects this may not always be possible. Some features may be simple, while others may be complicated, possibly spanning multiple builds and releases. Some problems may require extensive up-front detailed use case analysis and extensive finite state modeling (like complex banking transactions, for example). These may not fit neatly into small, bite sized stories. Hybrid solutions can be deployed in such cases to separate these technology risks into larger features and stories and extensive analysis, design and documentation performed only for them. You can still use Agile methodologies to drive the development but you fall back to traditional methodologies with detailed requirements gathering, analysis, design and modeling for complex parts of the project.
- Rapid cultural change difficult for development group: Agile development involves a faster pace of communication and development with daily or weekly standup meetings. For development groups that are used to longer development cycles with weekly and monthly status meetings, the pace of development and communication may be too much of a rapid cultural change. The development group may be going through the motions of Agile development but may not have bought into it fully. In such cases, rather than railroading the Agile methodology through the development group, it may be better to take a hybrid approach and implement Agile methodologies at a more sedate pace. It is easier to effect cultural change and get a buy in from development groups if they see the advantages of an agile approach in practice. You can then wean them from the older methodologies slowly. Critics of the hybrid approach often claim that Agile works only if development groups drop their older methodologies and switch over. That rarely works in practice. Organizations that have tried this often get soured totally on Agile methodologies and switch back to their traditional ones.
- Change difficult for other stakeholders: Agile methodologies are just as much a cultural change for other stakeholders like user groups, especially if an application is inward-facing. They may be involved extensively in requirements collection, design and even stand-up meetings. When traditional methodologies are used, the demands on their time and attention may not be as great as when Agile development is used. Would they be comfortable with the speed and the possible, increased involvement that Agile demands from them? Would they be comfortable with testing and providing feedback on lots of builds and releases? End users mistake intermediate builds and releases for the finished product and may be complaining about the lack of this feature or that. Are they comfortable with the incremental building of a software application? Hybrid methodologies may strike a balance between the two extremes, something these other stakeholders may be much more comfortable with.
- Contractual obligations: With outsourcing and off-shoring situations, detailed requirements and analysis may be needed before a proposal is made and a contract written out, possibly as a fixed price one. In such cases, clients may be very uncomfortable with having a time and materials, open ended, Agile approach. What do you do in such cases? Hybrid solutions allow the initial exploration of requirements and design at a detailed level while once the contract is in place and development starts, you can still use an Agile development method for development. Hybrid solutions may accommodate addressing contractual obligations and still using an Agile methodology in an elegant way.
- Distributed development groups: Following Agile methodologies becomes difficult if the development groups and the stakeholders are all geographically distributed. Agile methodologies work best if all stakeholders are able to meet in person and communicate. Phone, Web conferences and even periodic in-person meetings are poor substitutes in such cases. However, hybrid solutions may bridge some of these hurdles by introducing more written communication in the beginning of the project with detailed requirements and design documents. Weekly standup meetings may be more practical, and sustainable, than daily standup meetings. In addition, you can use every communication mechanism available; instant messaging, phone, Web conferences and periodic in-person visits.
Agile methodologies are successful because they enable communication, early and often, in a software development project. Traditional methodologies emphasize detailed requirements gathering, analysis, design and documentation. The rapid cultural change that Agile methodologies often demands may be too much for some development groups as well as other project stakeholders. Hybrid solutions strike a balance between these approaches and may be more successful than either approach alone.