RAD, Agile and: the good, the bad and the ugly on the Waterfall method

Posted on September 27, 2010

3


Introduction

About 50 years ago, programming even the simplest routines was a time-consuming business and compiling code happened in overnight batches. In that time it was very relevant to paper-prototype everything as extensive and specific as possible as – once you started in a specific direction – it was hard to turn around and change the script. From that period in time, the Waterfall method was developed. That time is long gone.

Nowadays when you want to prototype, the fastest way is in code (where “code” means “use 4th generation programming environments”). In a matter of days you can build the basis of entire applications and then start refining and improving them.

Using this as a starting point, you can invite your Client within weeks after you started building stuff to take a look and give feedback on what is there already. You can also take the feedback from the client and implement that in one of the next development rounds, improving the application every next cycle you work on it. Your teams can be minimized, as the tools, components and the Commercial- and Open Source libraries available fill in many of the things you otherwise had to do yourself and your project can move faster.

To write detailed low level design documents in this process is overkill. Even to write the detailed high level design documents is not required anymore. As you build and as you continue to involve the client and the target audience it is designed for, the software will evolve. What was covered by detailed design documents: written to cover every possible use case the writer could imagine can now be covered by test cases.

Still, especially in larger projects, the Waterfall method is used.

Nowadays Waterfall is achieving the opposite from what it was intentionally developed for. Waterfall is a very inefficient method of software development. It introduces many risks including: Loss of quality / a sub-standard or inferior end result – due to the lack of immediate feedback with the client and lack of progressive quality rounds (including usability and review and redesign of initial design assumptions) Increase in cost – due to the size of teams and the amount of time it costs to go through the entire process Increasing loss of control with each next phase – due to the almost schizophrenic design process, where each next phase is more and more disconnected from the original intentions and needs that lead to the initial request to build the (software) solution and the increasing size and “dumbing down” of the teams.

Compared to more current development processes – like RAD in the late 1980’s and Agile in the 1990’s – Waterfall is losing more and more credibility due to a failure in delivering what is really needed by the Client while exceeding budget over and over again and failing to meet deadlines.

In my opinion, Waterfall is just as useful for software development as horse and carriage are for transportation. Even more to the point: except for working without any plan or design, Waterfall is the worst development method available. In this article I start with the Agile Manifesto, show the phases of a possible Waterfall and a possible RAD / Agile development process and quantify both based on three parameters:

  1. Avarage time needed per phase
  2. Average people needed per phase
  3. Number of phases needed to deliver the product

The averages are based on projects I did in the past. After presenting those two cases I compare the totals. I will also state some points on liability and will try to pinpoint why Waterfall still is used and why RAD / Agile is so hard to sell in organizations that still use Waterfall or buy the services of companies using Waterfall.

The Agile manifesto

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.]
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development.
  9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  10. Continuous attention to technical excellence and good design enhances agility.
  11. Simplicity—the art of maximizing the amount of work not done—is essential.
  12. The best architectures, requirements, and designs emerge from self-organizing teams.
  13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile manifesto restructured and grouped

When you look at the list above, it is a jumbled mix of conditions and actions. So I decided to tear it apart and put it in a more logical order. I could not get the numbering to continue, but these are the same 13 items as above.

Priorities and way of working

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Working software is the primary measure of progress.
  3. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  4. Simplicity—the art of maximizing the amount of work not done—is essential.
  5. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  6. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
  7. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Team

  1. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  2. The best architectures, requirements, and designs emerge from self-organizing teams.

Quality

  1. Agile processes promote sustainable development.
  2. Continuous attention to technical excellence and good design enhances agility.

Pace

  1. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Business people and team

  • Business people and developers must work together daily throughout the project.

Waterfall

The Waterfall method is still used in large projects, and it used to be very relevant when programming even the smallest routines was a very time-consuming business and a time where the world changed in a slower pace.

When you take a look at Waterfall in present times, it is primarily a very extensive form of paper prototyping: getting everything right on paper first, before you start programming. The main steps in Waterfall are roughly as stated below. The time frame is a ballpark figure depending on the size of the project.

Phase 1: Analysis – 3 to 6 months – 3 to 5 people

  1. Case studies / business process analysis – interviewing people, visiting locations. describing what processes are used now, where improvements can be made and where the process could be optimized
  2. High level design – based on the Case studies, describing what the system might look like and which parts it might comprise of
  3. Requirement documents – describing what is required for each part of the process
  4. Prioritization – using MoSCoW or similare methods – (MoSCoW is an acronym for: Must have, Should have, Could have, Would have.)
  5. Feedback process with client
  6. Implementation of Client feedback – by correcting and adjusting the designs

Phase 2: Planning – 2 to 4 months – 2 to 5 people

  1. Project goals – stating global deadlines
  2. Risk assessment – stating which parts of the application and realization might pose extra risks based on levels of complexity, “never done before (in our team)” and/or availability (of knowledge, people and expertise)
  3. High level project plan
  4. Feedback process with client.
  5. Implementation of client feedback – by correcting and adjusting goals, risk assessment and high level project plan

Phase 3: Design – 3 to 6 months – 3 to 15 people

  1. Functional design – describing what the logical parts of the application are, how they are connected, what they show and contain and how they reflect the requirements
  2. Interaction design – describing the interactions happening within the application. Historically this used to be a separate document. Tendencies are to merge Functional and Interaction design as they mirror a lot of the same information
  3. Visual design – containing the design and positioning of all visual elements
  4. Technical design – describing the components and structure of the application as it should be built
  5. Database design – describing the database systems required
  6. Test plan – a step by step test plan, based on the designs, aimed to create testing situations that will break the application

Phase 4: Realization – 4 to 10 months – 5 to 20 to 30 people

  1. Building the specifications – including the front-end, the middle ware and the backend
  2. Testing the implemented parts
  3. Reporting found bugs
  4. Fixing the found bugs

Phase 5: System Integration – 2 to 3 months – 5 to 15 people

  1. Bringing all the parts together towards a working system

Phase 6: Acceptance Testing – 1 to 3 months – 3 to 10 people

  1. Testing if the application meets the requirements and designs
  2. Reporting found bugs and deviations from the original design

Phase 7: Bug fixing – 2 to 4 months – 3 tot 10 people

  1. Fixing the bugs
  2. Testing the implemented fixes
  3. Reporting found bugs
  4. Fixing the found bugs

Phase 8: Repeat phases 4, 5 and 6 until no bugs found

Testing and bug-fixing are repeated until the application is ready and conform the specifications.

Phase 9: Release to client – 1 to 3 months – 3 to 5 people

  1. Demo to client – where the account manager shows the application and demos the functionaliteis
  2. Test by client – where the client tests the functionaliteis
  3. Feedback by client – which can contain of found bugs and changes in requirements (Change Request)

Phase 10: Implementing Client feedback – 2 to 6 months – 3 to 10 people

  1. Depending on the Client feedback the following can happen:
  2. Change request: start new proces from Phase 1
  3. Bug fixes: start process from Phase 4

Phase 11: Release to market – 1 to 2 months

  1. Release application to Live environment
  2. Test Live environment
  3. Fix bugs and issues due to new environment
  4. Release

Totals

  • Phases: 11
  • Release time: 21 to 47 months after start – iterations not counted as extra time
  • Individuals involved on average: 14 to 60 people

The disadvantages of the waterfall method

Waterfall has many disadvantages. Some are caused by the rigid flow – you can only go the the next phase when the previous is closed, some are caused by the way the teams and people work together.

Others are caused by the way Waterfall is implemented: the “Factory model” which will be clarified briefly later. I will list them here:

  1. Long time to realization – in the most optimistic situation in the example above, 8 months (3 + 2 + 3) have passed before building starts
  2. Strong dependency on the qualities of the designers – There are many things that can go wrong here. I list two of them:
    1. The design documents are incomprehensable for the client. Simply put: the client has no clue what is communicated to him/her.
    2. The designer uses the wrong assumptions in the design. For instance: thinking something is impossible based on incomplete information
  3. Long time to client feedback on the actual thing – in the most optimistic situation we talk about 12 months after the project started
  4. Long time to Client feedback – we first need to pass phases 4,5 and 6, taking another 7 to 17 months in the most optimistic case, as we did not count the repetition of the bugfixing cases.
  5. It takes a lot of people, a lot of time and costs a lot of money – Each phase has it’s own team of 3 to 10 people on average, growing with something like 2 people the more you go down the line. When you reach implementation, the team in that phase might count 20 people
  6. No guerantees on quality – the security that Waterfall seems to give on quality, due to the process, is a fake security. See the next items in this list.
  7. There is no / or hardly any internal feedback up and down the line – when designers are done designing, their documents are passed to the next phase. In most cases other people pick up their work and start to do theirs. Where there should be feedback sessions between the different people usually there is none. In most cases because the manager lacks the experience and awareness of the importance of this. The result is that in most cases in each next design new assumptions are made.

Many organizations using Waterfall have a very strong hierarchy and follow the Factory model: “each employee has a very specific task and will be handed those tasks by his / her manager”. In this type of organizations there is limited room for feedback processes and re-design processes. “You do as you been told” whether that makes sense or not.

The client usually hardly understands the documents – the result of this is that a “OK” is given on something that HOPEFULLY will help meet the client requirements Based on these and other experiences and based on an increase of better tools, other design processes emerged. Remember that the Waterfall method was designed in a time where “programming” consisted of punching holes in paper cards.

What does the Waterfall teams consist of?

In most cases they are not teams, but individuals working in closed cubicles on their own specific part of the project. The main reason for this is that – what I call – a factory-model is used (everyone gets a task, performs that task and does as told) instead of the model you use for design processes (the entire group is responsible to deliver a result and works together to get there). This article will not go into the disadvantages and mistakes of using the Factory model. Each phase has a different setup. So I approach them one by one.

Phase 1: Analysis

  1. One or more Business Analysts, analyzing the client processes and writing the cases and designs
  2. A project managert
  3. An account manager

Phase 2: Planning

  1. One or more Business Analysts, analyzing the client processes and writing the cases and designs
  2. At least one project managert
  3. An account manager

Phase 3: Design

  1. At least one Functional Designer
  2. At least one Interaction Designer
  3. At least one Graphical Designer
  4. At least one, but usually 2 or 5 Technical Designers
  5. One Database Designer – if no system is present or additions need to be made

Phase 4: Realization

  1. Front end – at least 1 to 2 programmers – each given a specific set of requirements
  2. Middle ware / Business layer – at least 1 to 2 programmers, each given a specific set of requirements
  3. Backend – at least 1 to 2 programmers, each given a specific set of requirements
  4. At least one Project manager

As Waterfall, due to the granular designs, theoretically can be used in a factory-type of approach, where you can plug in more people to cover the requirements, you can expand the team of programmers with more people if that is required. The basic premiss is: If one person can dig one hole in one day, ten people can dig ten holes in one day. I mention 5 to 30 people on the Realization phase because “plugging in more people” is sometimes the solution used to reach the deadline in time.

Phase 6: Testing

  1. At least one tester
  2. At least one test manager
  3. At least one person who writes the test scripts

Phases 6 to 10: from bug fixing to release As these phases are usually done with the people from phases 3 to 5, the lists repeat.

Why RAD, Extreme Programming and Agile emerged

As time passed, the tools to program offered ever increasing improvements in speed of delivery. With todays tools and development methods you can build applications in one day that would have taken months to build 30 years ago. Bottom line Waterfall means and meant:

  1. An incredible (according to current times) long development process to get to a working result
  2. Very high costs, due to all the people and processes involved
  3. A result that is exactly according to the documentation but in most cases not meeting it’s purpose.

RAD started to turn the process upside down. The idea was to:

  1. Involve the client from day one
  2. Show a working proof of concept of a working application as soon as possible
  3. Work together with the client to gain results
  4. Finalize and stabalize aspects of the application
  5. Expand with each next development phase to implement more and more refinements.

The RAD/Agile process might look like this:

Phase 1: Requirements – 1 to 4 months – 3 people

  1. Case studies / business process analysis – interviewing people, visiting locations. describing what processes are used now, where improvements can be made and where the process could be optimized
  2. High level design – based on the Case studies, describing what the system might look like and which parts it might comprise of
  3. Requirement documents – describing what is required for each part of the process
  4. Prioritization – using MoSCoW or similare methods – (MoSCoW is an acronym for: Must have, Should have, Could have, Would have.)
  5. Feedback process with client
  6. Implementation of Client feedback – by correcting and adjusting the designs

Phase 2: (Rapid) Prototyping – 4 to 10 months – 5 to (maximal) 15 people

  1. Create a small and interdisciplinary team, consisting of one ore more programmers, one or more designers, a high level designer and the account manager.
  2. Sit down with the client from day one
  3. Write intermediate designs: describing what the application or application parts should do and what solutions are chosen to make it work according to the specifications
  4. Build prototypes on the fly, based on input by the client
  5. Correct, extend and rewrite application parts
  6. Try and test if these protoypes do what is intended
  7. Write down (log) the feedback of the client
  8. Implement the feedback in the next phase
  9. Come to a final Working Proof of Concept

Phase 3: Refactoring the prototype – 1 to 2 months – 3 to 8 people

  1. Restructure the parts, rewrite bad code, extend code with better implementations
  2. Testing use cases
  3. Fixing bugs
  4. Deliver a new Working proof of concept

Phase 4: Repetition of phase 2 and 3 until satisfied Phase 5: Testing and fixing – 1 to 2 months – 3 to 8 people

  1. Create test scenarios based on the use cases
  2. Adjust and extend the test-datasets used during prototyping the applications
  3. Test the application
  4. Fix the bugs and inconsistancies
  5. Repeat steps 2,3 and 4 until satisfied

Phase 6: Release to market – 1 to 2 months – 3 to 8 people

  1. Release application to Live environment
  2. Test Live environment
  3. Fix bugs and issues due to new environment
  4. Release

Phase 7: Documentation of product – 1 to 3 months – 3 to 5 people

  1. Technical documentation
  2. Functional documentation
  3. System documentation

Totals

  • Phases: 6
  • Release time: 8 to 20 months after start – iterations not counted as extra time
  • Individuals involved on average: 4 to 15 (the team hardly changes and more than 15 breaks the effectiveness of the team)

As “Integration” already takes place during Phase 2, no extra time needs to be spent on that. Each part is built as a part of a working application.

Differences with Waterfall

  1. The team remains unchanged during the entire process – so that everyone involved understands all aspects, including the Client interests and the reasons why to- or why not to proceed with a specific design direction
  2. The design is fluid until the last day of prototyping – based on Client feedback and discoveries and new insights during the design process, adjustments can and will be made
  3. “System Integration” is done from day one. There are no isolated parts – except for Working Proof of Concepts used to find out if a specific design direction will be effective for the application.
  4. To deliver a product that satisfies the needs of the client is the prime directive in all stages. This includes:
    1. Meeting the needs and requirements the client specifies
    2. Being stable and bug free (as far is possible to test and repair)
  5. The client is involved from day one and during the entire process – the designs will be made with the client. Working proof of concepts are shared with the client. Feedback from the client is immediately put back in the process to be implemented in a next development cycle.
  6. The system evolves, instead of being designed – based on the feedback and increasing insight, the system evolves every next cycle. This evolution includes:
  7. Dropping requirements that are of no added value
  8. Adding new requirements that will improve the usability and added value of the system
  9. Changing design directions for other alternatives that offer better results to the Client’s needs
  10. The programmers and designers are involved from day one – allowing design-decisions to be made that can save time and deliver the same – or even better – possibilities
  11. Documentation is written afterward – taking that away from the time needed to deliver the system to the market
  12. The time to market is dramatically shorter – 50% and more
  13. Less people are required and involved to come to the same result – due to the stability of the team, the working together of disciplines and possibility to make ad-hoc changes that increase the efficiency and effectivity of the development process.

What does a RAD / Agile team consist of?

  1. One or more architects – doing the high level designs, the case studies and the interviews with the client and involved and leading technical part of the project
  2. One or more front end programmers – programming the front end and all components needed to make the application work according to specs
  3. One or more middle-ware programmers – programming the business logics and in most cases also designing the (connections to the) database system(s)
  4. One or more designers – registering the client feedback, making the wireframes, the visual designs and interaction designs
  5. One or more testers (optional) – testing the application, creating test data and test scenarios
  6. One account manager (present when the client is present), dealing with the client
  7. The client – giving feedback on the results in each and every stage of the process, checking if his needs are met, brainstorming with team to see where improvements can be made now, instead of next year.

Putting the numbers together

Remember that these are ballpark figures. There are many factors influencing these numbers, including: level of expertise, level of experience with a given approach and level of experience with the used technologies.

Waterfall totals – ballpark

  • Phases: 11
  • Release time: 21 to 47 months after start – iterations not counted as extra time
  • Individuals involved on average: 14 to 60 people (taken that the account and project managers are the same during the project and the team that coded /built the app is also the one fixing the bugs)

RAD / Agile totals – ballpark

  • Phases: 6
  • Release time: 8 to 20 months after start – iterations not counted as extra time
  • Individuals involved on average: 4 to 15 (the team hardly changes)

Wrapping it up

The numbers and descriptions given here are intended to give you an impression of the differences between RAD / Agile type of approaches and the Waterfall method. My personal experience is that: Using Waterfall leads to long development processes, very high costs, a lot of overhead and results (due to it’s rigid design process) which are working according to the specifications but below standard of what COULD have been achieved in the same time and less people. (I use the word “crap” in general) Using RAD / Agile type of development processes lead to a very short time to market, higher client satisfaction (as the client is involved in the process, the product is improved DURING the development process) and a better result using less people and spending (significantly) less money. Waterfall focuses on documents and processes. As long as you write enough documents and have them signed off by the client, you are OK. Somewhere down the line it is important to have a good result, but if the documents are already written, these improvements can only be implemented in the next phase. A year or so later. RAD / Agile focuses on the client, deadlines and the result. At the end of the day, there has to be a working result, that covers all the needs expressed by the Client, delivered on time.

Money machines and money drains

At this point in time – in my opinion – Waterfall is a money machine and a money drain. The “money machine” part is at the side of the party applying Waterfall. Waterfall allows them to charge a lot of hours for a lot of people. Waterfall also allows them to utilize low cost, junior programmers (to perform very specific tasks) and charge the full price for each of them – as the client has no insight in the process, the quality of the people used and the effectiveness and efficiency of each. The money drain is at the side of the client. In the end they pay (in the mildest scenario) for twice the amount of development time with a team at least 3 times as big as a RAD / Agile based team, for a result that is crap.

Where Waterfall was useful

Waterfall was useful in a time where “programming” was a tedious and long process and “can we change this to that” would involve months of revising code usually written in machine language (“00100100 = multiply the given value by 2”)

Why Waterfall has become a dinosaur

  1. With the tools of 15 years ago, you can build working proof of concepts in days. MS Access is for that reason the prime tool of choice for many people in many offices. In a few days you have something that works and can be used by others. It is vulnerable as hell, but it works.
  2. With the tools of today you can build complex structures, use productivity tools to up your development speed and refactor your code, your classes and your code structure in hours time.
  3. With the design patterns that emerged, have been refined and have been documented you can build applications you can revise and rewire in hours and days, moving blocks of functionality from “A” to “B” and back.
  4. This means that as soon as is clear what the BASIC requirements are of the client and the eco-structure the applicaton(s) will be used, you can start coding. There are many ways back if you make a design mistake and the time to needed to build a working interface, test it and implement feedback IS LESS than the time needed to write the lower level design documents.

Why Waterfall is not used in smaller Web/software development agencies

The reason is short and simple: time and budget. Clients of smaller (web) agencies do not have the time and budget to go through an extensive design / documentation process AND get pissed off when the result is below standard. All the development teams and companies I know of starting with Waterfall – or something similar got hammered over and over again by failure until they gave up and started changing their process towards Agile. In all other cases (where they did not optimize their process) they died.

Why no process is bad as well

You need designs. You need to know what the client needs. You need to test. You need to have several rounds with the client to verify if the team and the result is still going in the right direction. You need to log the changes requested by the client. You need to log the changes made by the team. You need to document your work. You need to refactor. You need to review. If you do not do this, your products will fail. Your clients and your money will leave your company. In the end, your business will fail.

Why Waterfall is still used

The main reason I believe people use in general to choose Waterfall is the false sense of security you get. As everything is documented to the last single item to be produced AND the Account managers of the contractor seem to be nice guys with a clear story, use the right set of buzzwords and the “right type” of approach AND because it costs at least 1.000.000 euro, “nothing can go wrong”.

To understand this process: imagine seeing 2 offers for a car: 30.000 euro by Volkswagen and 5.000 euro by Company “X”. Which one do you think is best and safest choice? Very likely – based on only this information, price and brand – you choose the 30.000 euro Volkswagen.

A second reason why Waterfall is still used, I think, is due to the development team and the management of that team. Again: Waterfall seems a safe choice. In most cases, as “Writing solid and rugged design documents” is the leading directive, all (sometimes very clear) signs of where the development process goes wrong are ignored or not acknowledged.

The third reason Waterfall is still used is that the company or team has never been under the threat losing clients and / or moving towards bankruptcy. In brief: “why optimize your process if there is no reason to?” The fourth reason is liability. As each step is documented and (should be) approved by the client, you are not responsible for when things go wrong on the client side – as long as you meet the specifications as agreed in the documents.

The importance of documentation

Waterfall states that proper documentation prevents loss of time in later stages of the project: due to making the right decisions as soon as possible. Documentation also makes the project easier to transfer. If someone leaves the project, the knowledge of this person or about the part he or she was building is not lost. It is documented.

As this is true for all design processes, the question is: up until what level do you need to document? In most cases of software-development I know:

  1. The code is your documentation – using remarks and clarifications in the code
  2. The code-design is your guide – using design patterns, clear organization of classes in clearly defined class packages (stored in folders) and the use of clear -telling- names for methods and variables (using “personIsAddedToCompany” as a variable name instead of something like “ptcTrue”)
  3. Documentation is used as your guide in – telling you where to start, where to look and how everything works together.
  4. Quality Assurance and Readability is done by peer reviews – using the feedback of your fellow coders (“I do not understand what you do here”) to clarify and refactor your code

As the details changes while round after round of adding more functionality and rewriting parts of your code, detailed documentation up front is only adding more work to the process. In Agile, in most cases, the documentation up front is a registration of the design process: giving general directions of how the application will be setup and which logical blocks will be used to make the parts work.

The details will be available in the code.

Why RAD / Agile is so hard to sell in a company using Waterfall

Compared to Waterfall, RAD and Agile seem to introduce a lot of risks, as nothing is really documented, the cost seem ridiculously low compared to Waterfall (at least 30% less but very likely up to 80% less) and the process can be described as “we start building with a minimum of design and correct and improve stuff along the way” which sounds like: “we have no clue what we are starting and will find out along the way” which – when you are used to control all processes by descibing every little part of it – automatically leads to the assumption of: “no control over the result or the time needed” which stands equal to “proned to fail”.

When a company already got burned on their past results due to delays and being over budget, any new approach that has not been proven internally or externally (based on the information available in the perception of the people judging this) any new method introduces the new risks of the unknown.It could be better, but very likely it will be even worse.

Liability might be another reason not to choose for RAD / Agile. As “nothing is documented in a proper process” (I come back on that below in “Conditons” to show how an Agile process would deal with that) when things go wrong between client and contractor, the contractor would be liable and thus fucked.

Why you have to protect yourself

When you build software, you usually build that to assist or facilitate some or another commercial process. This can be an online campaign supported by commercials pointing at a website you have to build, or a product that has already been pre-sold to clients and has to be delivered on a specific date. In most cases, when your client does not meet that deadline and is unable to deliver OR the software itself is not doing what is expected the nastiness starts. This nastiness contains of three words:

  1. Lawyers
  2. Claims
  3. Damage

When you and your company are not able to deliver what was needed or within the deadline for whatever reason, the claim will be transferred to you. In that case you better be able to prove it was not YOUR fault. If you are not able to do so, your company will not be the first one driven into the grave due to the inability to deliver on time.

Agile and RAD achieve what Waterfall pretends to deliver

In most cases, Agile and RAD achieves what Waterfall pretends: more control over time, cost and the development process and in many cases Waterfall fails in what it pretends to assure: quality of the end result, control over development time and control over development cost. The end result of Waterfall is in most cases a bad fitting suit, made by people who have no clue and do not communicate, for at least 6 times the price and 3 times the time you need to spend and wait when you go to a proper tailor.

Conditions to meet for successful Agile / RAD projects

  1. You need your most experienced people – You need the people who would normally write the designs. People who know how the business work, how to write software and how to find out what the Client’s processes and the Client’s needs are.
  2. You need people who know how to code – If you use Juniors to write the code, you will end up with linear implementations which will be hard to change when the requirements change.
  3. You need people who know how to design software – Including the knowledge of design patterns and best practices to build stuff.
  4. You need people who are to the point / dare to make decisions – I have seen many “software design sessions” where after three meetings still it is not decided whether a success/failure state should be returned as a Boolean or a String
  5. You need the best tools available – Do not try to be smart and save on hardware or software. I have seen people working on (the year 2010) 3 MHz Pentium computers with 1 GB of RAM and not having access to applications like Enterprise Architect. Which is the same as giving a Porche crippled with the engine of a moped to a person who needs to bridge 100 KM in the shortest time possible.
  6. You use clear naming and clear comments in everything you build – each class and each pice of code should read like a story. Variable and method names should be self-explenatory.
  7. You need a clear process to keep control over your time – Scrum is the fashion in the past years. I am not a fan of Scrum due to the focus on “do what you choose / what is assigned to you and report what you did” without any explicit drive on deadlines. Because of that I vote for timeboxing as a better approach.
  8. You need a clear process to keep control over the project scope – Involving the client in your process is wonderful for everyone. It makes a better product and makes a better process as well. But one risk is that every meeting will lead to even more work, without moving the deadline further away. MoSCoW is one of the ways to avoid ongoing Increase of scope
  9. You need a clear process to warrent quality – especially in RAD / Agile processes testing is an integrated part of development. It is easy to overlook the importance of thorough testing. One way to solve this is to have one person being responsible for Quality.
  10. You must document everything that is agreed on between you and the client – Each next phase is documented in brief: what new requirements are defined, how many time this will take, what the involved cost are, what the impact will be on the deadline, what will be built, what will not be built, what will change due to the new specifications. Each document is a new contract between you and the client.
  11. You must get explicit approval on each documented next step – As said: each (new) document is a contract between you and the client. If you do not ask and get explicit approval. If you start building stuff without the explicit consent by the client and when you and the client get into a dispute, you are liable and thus fucked. Even when the client agreed with the changes verbally.

I started this article with the Agile manifesto and restructuring it. I will end with the first seven lines of the restructured manifesto. It describes clearly where Waterfall and Agile stand apart and why Agile was developed. Very likely it makes even more sense now.

Restructured Agile Manifesto, 1 to 7

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Working software is the primary measure of progress.
  3. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  4. Simplicity—the art of maximizing the amount of work not done—is essential.
  5. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  6. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
  7. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Advertisements
Posted in: Uncategorized