- April 8, 2016
- Author: admin
- Category: Agile Methodology
For all that the world in general, and businesses that are IT dependent have had to endure, Waterfall, I daresay has been spared, and in fact pampered like a spoilt child. I am not anti-Waterfall Project Management- don’t get me wrong. I am just anti-redundancy. The Waterfall Model demands that one stage of the software development life cycle is ‘complete’ before the next one. There is one simple question it fails to answer- “What if the people wanting this software change their mind?”
In many ways, the much celebrated ‘Waterfall Model’ has slowed down progress and cost people unnecessarily. I used to be a Waterfaller, until the pressure of the waters falling weighted me down- literally! I am an Agile-r now. If you want to call me that.
- All- yes, all requirements are gathered at the very beginning, in a span of 3- 5 months depending on the size of the project.
- Requirements are more from the system’s ability to satisfy a feature, as opposed to getting the user to use the feature. The outcome of this stage are huge documents, which unfortunately, people will not read- even if you put a Harry Potter cover on them.
- Once these documents are out, designers tend to jump onto whatever is written first, or whatever they feel comfortable doing. No real priority is assigned to the work.
- An elaborate plan is drawn, listing out when what feature will be completed. Like all plans, these are meant to break- but they are so fragile with no real buffer, making Waterfall one of the most painstaking models to be working with.
- Requirements are looked from a bird’s eye view. When the project team’s core members meet with the client, they spend about 2 to 3 weeks listing the requirements, forming an agreement to keep some features in scope and remove some out of scope.
- Requirements are always from a user’s point of view, and they evolve, so pages and pages of documentation is not delivered. In fact, just an excel sheet containing the list of features, broken down into stories is the only deliverable from the requirements phase. These stories may be broken down, or new ones added depending on what the client needs, when the story is being implemented.
- These stories are prioritized as well, hence designers and developers know which chunk of stories to begin with.
- Plans are made, and broken too, but their breakage does not signify wreckage!
- There is usually no dedicated user experience person – only a graphic designer who will provide visual designs, but not meaningful user experiences. A user experience is how the user will use the system and how it will behave given a set of conditions the user executes. Most often, a lack of this experience is what leads to dissatisfied customers and consumers.
- Usually, the graphic designers are not in house people. In case a client needs a change to the design in the technical design stage, finding a graphic designer could be challenging.
- At inception user experience (UX) consultants work closely with the clients to identify the critical and useful user journeys. This way the information architecture can be put in place by the UX consultants later, and a meaningful journey derived.
- UX consultants are usually in-house folks staffed on a project full or half time depending on the workload. So, if there is indeed a change required, rework is quick.
- One of the most riskiest things to do is design your database and architecture well in advance of the real implementation. The reason is simple: your client, or his consumer’s buying behaviour might have changed.
- In that case what holds good now will not hold good in a month’s time when implementation begins, let alone client demos!
- Agile does a solid technical design, but tries to keep the module as decoupled as possible. Agile works from the inside. The nucleus or the core of the design is built first.
- Surrounding that, a framework of how the design must be, is ideated. This means that design is done on the go, thus providing room for change.
The Big D
- Development begins probably 4 months down the line. By then, the clients are probably thinking of an alternative solution to the problem, or even not looking at the problem like a problem.
- There is a lot of software churn, but there is no way the client will know what is being developed unless periodic demos are conducted.
- Agile employs a method called Continuous Delivery, which is development of a meaningful set of stories on a regular basis and delivery it to the client so that it is of some business value.
- This way, the client gets to see parts of the solution already making some business value, hence, mutual trust is also built.
- Waterfall unit tests are done by developers after they have finished writing the code.
- In most cases, this is only a ritual, and developers fail to look at alternate, edge, and error cases. If they had been looked at defects could also be fixed.
- Agile developers do test Driven Development: They write failing Tests before they actually code the functionality. This ensures that all alternate, edge and error scenarios are covered. After development is done, Agile developers ensure that all their unit tests are automated.
- Doing this in smaller portions ensures that all stories indeed have tests written, and that testers can be assured of the basic regression scenarios being covered.
- After about 6-8 months since the project itself had begun, begins testing. By this time, any changes the client requests will be ‘charged’ as change requests.
- Also, vigorous but not prioritized testing takes place, and not all cases might be covered, because testers get involved in test case writing only when development begins.
- Agile testers join the bandwagon as early as week 2. As soon as the BAs write stories and as soon as development beings. Manual as well as automated testing is performed.
- Also, a regression test server is kept on all the while, because delivery is continuous and there may be numerous builds per weekly/biweekly iteration.
By the time all the cascades of the waterfall are done with, the clients perhaps are going to be happy with the outcome, but they also know any changes will be a pain. They are possibly going to have to make do with what they got.
Every iteration, the client gets to see what value each bit of software is doing for them. Hence approval is instant, and clients are free to give feedback if they would like changes. How quick is 2 weeks, as opposed to 9 months!
Mostly, feedback is given only during the requirements gathering phase, and in the approval phase. The clients do not get to see the product entirely, and frequently working prototypes are shown in demos.
Since there is a churn of working software every week, feedback is instant. Any changes do not go through a strenuous change request process.
Mostly, the users get to see the product after a very long time, and even in BETA changes are mostly difficult to make.
Even before a BETA, select users undergo participate in a testing process, which helps clients and the project team to better gauge the usability and simplicity of their design, and ultimately, their software.
Sign off and Release
- There is no major difference in the sign off process of both models, except that the build-up to the release is much more strenuous and pressurizing in the Waterfall model. In the Agile model, every small iteration is evenly spaced, so there is no rush at the end of the project.
- That is my understanding of the two arch-rival software development lifecycle models. Amateurish as it seems, written in layman words, I am in no favour of the superfluous words that the Waterfall model demands.
- Whilst this is purely my observation, I have noticed that in the last few years Agile is spreading like wildfire – and I am afraid, not in the very true sense. There are claimants who boast Agile, but then you know what comes best of half baked knowledge.
- I am an Agiler now, like I said. But there may be a day when this becomes legacy too!