There is a lot of discussion today (and in recent years) around development approaches … specifically waterfall or agile. If you are unfamiliar with the terms, they define the overall approach of the software development methodology. In this article, we provide a brief overview of each and discuss our approach to development.
Waterfall
In waterfall, regardless the size of the project, the team will try to identify ALL of the requirements of the software application before coding. This results in a lot of effort creating many written pages of something called a design document that is then handed off to developers whom often get it wrong. When it does come time to present the finished solution, often it is not what the customer wanted but with many hours invested. This was and still is the development approach used by many large IT shops. This can work if you have lots of time and money.
Agile
Alternately, agile says that trying to anticipate exactly what the system will do, who will use it and how, is impossible. So, agile takes manageable pieces of the effort and starts prototyping or coding early in the development process. Once a piece is complete, it can be demonstrated to the client, discussed, and revised. Feedback around the application is started much earlier … usually within a month or so depending on the size of the project. It is in this way a closer relationship between the project team and the users is established and a “meeting of the minds” occurs much sooner. Also, time invested is limited so corrections can be made in every way on the (i.e. leadership, team members, business liaison, etc.) if necessary.
Agile for Adage
At Adage, we adhere to a more agile (or iterative) approach in doing development. We firmly believe that the benefits of being able to adjust requirements based upon business needs significantly outweighs any would be efficiencies that might be found in a more waterfall approach. And, in fact, many experts challenge the notion of efficiency in waterfall. Some believe that application development is a practice that will actually create diseconomies of scale when taking on larger projects.
The developer is key
One of the secrets to doing agile effectively is that you must put a lot of control in your developer’s hands. They must be able to work with the client in establishing the requirements and then translating those requirements into a solution. This requires that the development team views themselves as solution providers NOT technical resources. The development team (right down to the junior developer) MUST accept responsibility that it is their job to MAKE IT HAPPEN. It also requires that the development team is actually a team, not a collection of individuals.
Tools
The development team must be given the proper tools to engage a project with the ability to be able agile. Some of the tools necessary to be successful at agile development are the following:
Must Haves
- Robust source control that allows for significant branching and tracing
- Automated Unit Testing
- Automated Build Server
Nice to Haves
- Code Generation Tools
- Shared online list of requirements
Team Structure
Since all projects are always a little different it is important to note that the structure identified below is more of a guideline.
Project Manager – This person is of course responsible for the overall project delivery. Given the size of the project, this may be a part time role or full time. The person is responsible for working with the project team members to ensure progress is being made and make adjustments as necessary. The project manager is a member of the delivery team although given the size of the project, a the business group may also have a person acting as a project manager on their behalf as well.
Application Champion – This resource should act as the liaison between the end users, the business owners, and the developers. It is their primary responsibility to triage any requirements from the end users or business owners to identify risk, cost, and benefit. The Application Champion understands the application not just from a “what does it do” but also from a “what problem is it solving” view point. While this person can “stand in” for the business owners or the end users when the developers have questions about requirements, the goal should be for the developers to interact with all parties.
End Users – An end user is someone who works with the application on a day to day basis. This resource has significant knowledge of the system. This resource also can have great insight on improvements to functionality and should be encouraged to share that insight with the Application Champion.
Business Owners – A business owner is a person who is ultimately responsibility for the success of the investment in the application. This could be the actual owner of the business or a manager who pushed for an application. In short, they understand the business requirements that must be met so that the application can be a success.
Developer – A developer is a resource that works with the Application Champion directly to do cost benefit analysis on requirements. They also will interact directly with the end users and the business owners so that they can understand the requirements completely. They are responsible for translating the requirements into a solution.
Conclusion
In many cases , your approach can hinge on time constraints, money, and resources involved. For instance, waterfall may be a better approach if you have a collection of developers and not a true development team. Or, where communication gaps exist (i.e. offshoring) and everything can be prototyped and documented extensively. But this typically will cost more money in requirement gathering and documentation on the front end and testing on the back end of the project with less of a chance to “get it right” from the business user’s perspective.
For agile to be successful, you need a well practiced development methodology and the development team to back it up. If you don’t, your results could end up being worse than using a waterfall approach with poor developers. Agile development requires discipline and practice.