What is Agile?
To begin with the context, one should understand the real importance of being structured. In providing software solutions, the field making it essential to keep on top of the latest developments in the industry to best serve clients. When a client is formulating a contract with a vendor to beat an existing solution by adding more features, it’s a challenging thing nowadays. Client requirements readily change with the market structure that relies upon the fast-paced world. If something breaks within the app portfolio, sooner you fix, sooner you will be confident. Thus a suitable methodology should be followed.
A view on the waterfall methodology issues…….
Among them, the waterfall model is a traditional methodology that sequentially follows user requirements gathering, analysis, design, construction, testing, implementation, and maintenance. Let me point a few issues related to this methodology. Say for example when you switch your phase downwards, you can’t go back in the ladder. Let’s say you have attained testing phase and your client is requesting you to add some new features, now you are about to start from the ground. There you will raise a concern showing the contract to the clients that it is impossible to mess up for adding new requirements. We have to make sure that we satisfy the clients making them flexible to raise suggestions and ideas to add on with the software solution.
Multiple implementations are there in agile. They are Scrum, Kanban, XP, and a lot more. In Agile certain values are intensively followed to overcome issues synced to the waterfall model.
- Skills and expertise vary among individuals. To create a successful solution, the interaction between onsite offsite team members is encouraged more here.
- Instead of documentation, the working solution is preferred here.
- Not only relying on the contract here it’s advised to make very flexible discussions between the client and the vendor.
- Sometimes clients may not be clear with what they want in the initial stage. So here the vendor is recommended to estimate the product version with just enough features on his own to satisfy early customers and giving feedback.
- Instead of delivering the big bang project, here the priority is given to module by module completion. This welcomes changing requirements even in the late stages of software building.
It falls under Agile methodology. Scrum practices certain things that enhance readiness for improvements through wins and losses. One of the widely used frameworks where you implement Agile is Scrum. Here we go through the waterfall in the iteration.
Scrum! How it works…
Let’s imagine we want to make an app simply say Uber. There are certain requirements,
- have to calculate fare using car’s GPS location
- ride requirements of passenger
- payment features where uber charges linked to the credit card as well.
- a precondition, postcondition requirements(eg: account authentication)etc
So all the requirements are collected and prioritized.
Scrum it actually goes with “sprint”.Sprint?… So assume the entire project will take a period of 2 years. But you will not be waiting to deliver. So what if you can give something to the client every 2weeks/2months or whatever. That can be a potentially deployable product, but it depends.
In the “product backlog”, the entire log has boxes of different sizes. All the requirements from start to end are categorized based on sprint inside those boxes. If the sprint is decided as 2 weeks, in accordance with sprint the requirements that can be accomplished, will be taken out into ‘‘current sprint backlog’’.
At the end of sprint time, a potentially shippable product may have resulted(increment). As per example, any one of the features will get resulted; location finder/ride request finder/accounting feature. If the requirement set of the sprint is incomplete it will be pushed to the next sprint. Before jumping into the next sprint, you have to do “spring retrospective”.
“spring retrospective”…..Say simply, before getting to the next sprint, it is important to note things that worked/didn't work properly, things that you’ve learned, what will be committed for the next sprint, etc. So team members will be ready with their own comments.
Subsequently, there will be a stand-up meeting among the team members to rush up with the things noted in a sprint retrospective. Without sitting in the chair discussing unnecessary stuff, here details will be clearly pinpointed.
Scrum board…
It tracks the progress. In each column it starts with the list of stories in the current backlog, tasks to be done, tasks started, and finally, those completed. There you come to the word ‘end’ :)
