Agile Methodologies

These days ‘Agile’ has become so prevalent that every developer must have come across this word. The word in the market is that Agile is the best way forward, though this isn’t true for every project developed but true for many of them.

In this article I want to introduce you to Agile, if you just heard the word ‘Agile’ and want to know a bit more then you came to the right place.

Agile is actually a simple development methodology, there are various types of Agile methodologies but all of them are closely related to each other and have same overall principles. In this article I shall details the overall principles that all the agile methodologies follow. It may be the case that I speak mainly about ‘Scrum’ methodology as I worked mostly in projects that used Scrum.

Before agile has been introduced all the software development projects has more or less the following lifecycle:

Requirement gathering -> Analysis -> Design -> Develop -> Test -> UAT Deploy -> UAT -> Live

Each stage of this cycle was carried out once for the entire project. All the requirements analysed once for the whole project, design the entire system at a single go, developed the whole system according to the analysed requirements and so on. The problem with this mainly comes from the important stakeholder of any software project, the end user. The end user changes his/her mind as they see different systems or as they start using the system. Because of this the end product after the entire lifecycle isn’t always according to the user’s exact needs/wants.

Now agile tries to solve this problem by carrying out parts of the above lifecycle multiple times over entire life cycle of the project. So, it looks something like this:

1. High level requirement gathering
2. Requirement analysis [for small set of requirements]
3. Design
4. Develop
5. Test
6. UAT [Go to Step 2 for next iteration]
7. Live

Note: The loop can carry on until live but this depends on the type of system being developed

What’s happening here is that the requirements are broken down into chunks and the process of designing, develop, test and UAT are carried out for this chunk of requirements. This doesn’t work with bad design, so agile insists on having good design.

At the end of developing for each chunk of requirements the system is shown to the end user and the next set of requirements are gathered. This helps the end user to have a continuous look at the outcome of the project rather than being a surprise at the end of the whole project and also gives the flexibility of changing the requirements as the project progresses.

This is just a high level view of Agile and there is a lot more involved but you get to know them once you start following these methodologies.

There are some keywords used in this methodology, just like any other methodology, which I shall just touch base:

1. Sprint: Each iteration of the above development process loop is called as a sprint. Each sprint can span for a minimum of a week to a maximum of four weeks. The sprint starts when the next set of requirements are analysed, to the point the code is deployed for UAT or even Live. Over the lifecycle of the project it is advised to keep the length of a sprint to constant.
2. Scrum: As the sprint length is short there is very little scope to lose track of the project, so the whole team comes together every day and each person briefly explains what he/she has done last day, say what they are going to do today and inform of any dependency on anything or any other team member. This meeting is called scrum. Now there are some guidelines about people who should attend and who should speak in this meeting. I shall explain this sometime later but keep in mind that agile works only if you customise it to suit your project, so feel free to define your own rules. One main point to remember though is to keep this meeting to the minimum possible length and take any long discussions out of this meeting.
3. Sprint Planning and Estimation: This is the meeting at the beginning of each sprint where the requirements are detailed by the business user, the development team queries are clarified and each requirement prioritised. Each requirement is also estimated during this meeting by the whole development team so that it can be decided on what requirements fit into the sprint.
4. Sprint Retrospective: This is another meeting where the team comes together at the end of every sprint and discusses how the completed sprint has been. All kinds of issues are discussed during this meeting, personal, technical or external, everything that is affecting the project, so that they can be resolved for next sprint and the development can be smoother. It is very important to have this meeting and resolve the issues that are raised during this meeting. Also during this meeting all the good points are mentioned as well, this is as crucial as raising issues as it helps in motivating the team and also helps in identifying where they are improving and where they are not.
5. Sprint Demo: This is the meeting at the end of the sprint where the whole team will give the demo of features developed during the sprint to business users. Sprint planning and estimations follows this meeting. So, it might be a good idea to do these two meeting immediately one after the other.
6. Velocity: This is a bit tricky to understand but for this introductory article I shall just put it in easy terms. This is the speed at which the team is developing. This figure will be low at the beginning of the project and should increase as project progresses. If it isn’t increasing then the team need to figure out why it isn’t and take necessary measures.
7. Story Points: This is the complexity involved in delivering each requirement. It is advised to estimate the effort involved for each requirement in story points, so that the velocity can be measured, but if you are happy to estimate in hours then go ahead with that, it doesn’t fail your project but it is hard to calculate the velocity and thus harder to see if the team performance is increasing or decreasing. Story points are normally numbers from Fibonacci series, so an item complexity could be 1, 2, 3,5,8,13,21 etc.
8. Product backlog items: This is the set of high level requirements that are gathered at beginning of the project for the whole project - well known in its short form of PBI.
9. Sprint backlog items: These are the set of requirements that are taken up to develop during a sprint. SBI should be a subset of PBI. There are some rules defined about PBI and SBI but again feel free to write your own according to your project demands.

There might be few more terms that I forgot to mention but these terms should let you get started and understand if someone is speaking about Agile.

Keep in mind that Agile works best if it is used as a guideline and when the process is customised according to the requirements of the project rather than strictly following it to the word.