Warerfall Vs Agile

Technologies are constantly changing and so do management methodologies. What worked yesterday might not work today, and vice versa. How can you then be confident that your project is managed correctly?

We are experiencing a real boost of project management approaches and methodologies. In the IT world, the most widespread and popular one is, of course, Agile. However, there is no “one size fits all” when it comes to software development, that’s why it is crucial to know your project scope first.

We recommend using Waterfall if: 

·           You don’t expect changes in scope and you’re working with fixed-price contracts

·           The project is very simple or you’ve done it many times before

·           Requirements are very well known and fixed

·           Customers know exactly what they want in advance

·           You’re working with orderly and predictable projects

And you should use Agile if:

·           The final product isn’t clearly defined

·           The clients/stakeholders need the ability to modify the scope

·           You anticipate any kind of changes during the project

·           Rapid deployment is the goal

When deciding between Agile versus Waterfall, it can all boil down to this: if you anticipate or expect any changes throughout the project, go with Agile. If you know the project is fixed, unchanging, and predictable, Waterfall may be a better choice.

Drawback Waterfall

·       One area which almost always falls short is the effectiveness of requirements. Gathering and documenting requirements in a way that is meaningful to a customer is often the most difficult part of software development, in my opinion. Customers are sometimes intimidated by details, and specific details, provided early in the project, are required with this approach. In addition, customers are not always able to visualize an application from a requirements document. Wireframes and mockups can help, but there’s no question that most end users have some difficulty putting these elements together with written requirements to arrive at a good picture of what they will be getting.

·       Another potential drawback of pure Waterfall development is the possibility that the customer will be dissatisfied with their delivered software product. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until it’s almost finished. By that time, changes can be difficult (and costly) to implement.

Drawback - Agile

·       The very high degree of customer involvement, while great for the project, may present problems for some customers who simply may not have the time or interest for this type of participation.

·       Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the allotted timeframe. Additional sprints (beyond those initially planned) may be needed, adding to the project cost. In addition, customer involvement often leads to additional features requested throughout the project. Again, this can add to the overall time and cost of the implementation.

·       The close working relationships in an Agile project are easiest to manage when the team members are located in the same physical space, which is not always possible. However, there are a variety of ways to handle this issue, such as webcams, collaboration tools, etc.

·       The iterative nature of Agile development may lead to a frequent refactoring if the full scope of the system is not considered in the intial architecture and design. Without this refactoring, the system can suffer from a reduction in overall quality. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.

How to Estimate Budgets in Agile?

                                      

Estimating the cost before the project even starts can always be challenging, regardless of which project methodology you use. However, in an Agile project, you can tie the amount of time the project will take with its total cost.

First, create a burndown chart and use the burndown rate to estimate how many sprints will be in your project and when the project will end. Then, calculate how much the team will cost based on their hourly rates. Multiply each person’s rate by the number of working hours per week, then multiply that by the number of weeks in a sprint. Once you estimate the initial budget for your team, you can add any other costs, like technology, travel, or equipment.

You could also break down each user story into tasks. Once you have an idea of how many hours it will take to complete each task, you can estimate the project budget.

And lastly, you could use planning poker to estimate the effort required for development goals. Planning poker is a consensus-based, gamified technique for estimating the effort of development goals. Each team member makes estimates by playing numbered cards face-down on the table, instead of saying it out loud. The cards are then revealed and the estimates discussed with the whole team.Traditional cost estimations can take a lot of time, and they distract from the development team. There are various approaches that you can take in completing your cost estimations.

Burn Rate Cost Approach

The first approach is to work with your sprint session burn rate and period. Considering the sprint session has a fixed number of time resource units, it can be simple to work out the true cost if the cost of each resource is obtained. Depending on what costs are available to you, the approach can either be:

Average cost per person per hour. This is the simplest approach as you multiply the hours of each resource utilized during the sprint by the average cost you have been supplied. As an example, if you have one part-time resource and one full-time resource at $100 an hour (assuming 8 hours a day), a two week sprint would be (40 hours x $100) + (80 hours x $100) giving you a $12 000 per 2-week sprint cost.

Specific cost per person. This approach would require some additional calculations, where you will need to derive an hourly cost per person based on their annual salary cost. Once you’re down to an hourly rate, the calculation is the same as average cost per hour.

While this budgeting is a straightforward approach, its major challenge or downfall, is that it is heavily dependent on calculating the correct burn-down rate or scoring each agile task accurately. It also requires the tasks to have been estimated before you can turn the sprint cost into a project or solution cost. This only solves one part of the problem.

Another issue is that it doesn’t solve for the additional costs outside of the sprint planning. You will need to extend your costing model to provide for testing hours, administration hours, meeting hours and design hours.

Precision-alignment approach

Another approach is more budget orientated and less estimation orientated, and requires a set of business outcomes that are prioritized.

This practical example is based on an article by Debbie Madden writing for Harvard Business Review. Let’s assume you’re building an online retail shop for clothes. This business requirement can be broken down into a handful of areas that translate to major solution tasks, such as:

A landing page for marketing

A search function

A checkout function

Product pages

A customer knowledgebase

Order management system for customer agents

The next task is to then estimate, based on previous experience or some guidance from developers, what each task would take:



Task                               Time                        Budget



Store landing page                    2 - 4 weeks                   $20k - $40k

A search function                     4 - 6 weeks                   $40k - $60k

A checkout function                 6 – 8 weeks                  $60k - $80k

Product pages                           3 – 6 weeks                  $30k - $60k

A customer

knowledgebase                         2 – 4 weeks                  $20k - $40k

Order management

system                                      4 – 8 weeks                  $40k - $80k


This gives a first-sweep budget range of $210 000 - $360 000. Despite this wide range, the business can already make a decision if the minimum budget exceeds the resources available for this project, or is way under resources available. If the range is too broad for the business, you continue with the next step.Take all the tasks, and assign a priority to each one, which allows a distinction between ‘must haves’ and ‘optional maybes’:


Task                                    Time                  Budget              Priority


Store landing page                         2 - 4 weeks              $20k - $40k                 5

A search function                          4 - 6 weeks              $40k - $60k                 3

A checkout function                      6 – 8 weeks             $60k - $80k                 2

Product pages                                3 – 6 weeks             $30k - $60k                 1

A customer                                    2 – 4 weeks             $20k - $40k                 6

Knowledgebase 

Order management                        4 – 8 weeks            $40k - $80k                 4

system 

   

Blend to your environment



Both approaches take different directions but provide useful budgeting information for your agile project. You can combine elements of both approaches depending on how you have implemented agile principles in your organization. For example, if your agile environment is mature and you need to provide mid project sprint costs, the first approach is ideally suited. If your environment is less mature and the project is at an early stage, the second approach might be more suited as it quickly delivers cost approximations at the right stage of the process.

After the budget, comes discipline.

Two things will happen once you enter your project: you will either use fewer resources (time, money, etc.) or you will use more. Either way, daily management of the project and timely updating of your stakeholders is critical.

The situation that needs the most discipline and feedback is when you have detected that the project budget was under provisioned. Many times this is not a simple case of making mistakes during the budgeting process, but rather unexpected obstacles occurring during the project execution such as:

Delays caused by 3rd parties beyond your control

Rework that was unexpected

Resource unavailability, such as illness

External cost shocks, such as currency fluctuations