Raging Sanity Consultants, LLC
When feasible, Raging Sanity Consultants follow the Agile/SCRUM Software Development Methodology.
The Agile Methodology is the successor to what was previously referred to as RAD (Rapid Application Development) and has many benefits over the traditional Waterfall Methodology. Whereas Waterfall development is linear and focuses on tasks and processes, Agile development is team-based, iterative and focuses on people and deliverables. Each methodology has its own strengths and weaknesses, but whenever possible Raging Sanity Consultants prefers an Agile or at least a hybrid development Methodology.
Methodology Strengths and Challenges:
- Big, long-term resource commitments are not required.
- Higher priority items are delivered on quickly.
- Sooner visibility into real costs and benefits of projects and features.
- Nice-to-have features don't bog down the whole project. They are only implemented when there is a user demand for them.
- The customer has frequent and early opportunities to see deliverable components. This achieves greater user buy-in on the project.
- As new development can stimulate fresh ideas in the customer's mind, changes to requirements are more easily allowed.
- "Scope creep", within limits, is harnessed rather than feared.
- Because the customer is made a stronger part of the project team, they have a greater sense of ownership.
- Can deliver components with basic functionality quickly when time to market is a chief concern.
- Development is a bit more user-focused, which encourages greater user adoption.
- Works well when the customer is operating in a market or with a product line that changes rapidly.
- Does require a much higher degree of customer involvement.
- Works best when the development team is allowed to focus on just one project at a time.
- Because of the allowance for flexible reprioritization of the delivery schedule, and because new customer suggestions are allowed after the requirements phase, there is a greater tendency for projects to exceed initial estimates.
- Can be more challenging if project team-members are not co-located.
- If the full scope of the project is not considered at the onset, more frequent refactoring may result, especially in large projects or projects that require a great deal of systems integration.
- Deliverables are decided on early making planning and design more straight-forward.
- Facilitates a more efficient work process for team-members as they can engage in productive activities without having to wait for other members to complete certain stages.
- Scope of work is better known in advance and progress is more easily measured.
- With the exception of status meetings, reviews, and approvals, after the requirements of a sprint (a phase) are set, customer involvement is not required.
- Better allows for the development of multiple, even parallel components for integration with other systems.
- Achieves greater user buy-in and acceptance as they see periodic improvements that actually benefit them.
- It is much less of an issue if development team-members are not co-located.
- Identifying end-to end requirements for many customers is very challenging and time consuming.
- "Scope creep" is a real threat that can lead to disillusionment and failure.
- May be more challenging for customers to conceptualize intended deliverables.
- Greater likelihood that the customer will be dissatisfied with the deliverable as they won't see it until it is nearly complete.
Rest assured! We will help you identify the best approach for your organizational needs. Contact us today to learn more.
Raging Sanity Consultants, LLC