Late into my career, I decided to transition from my job in a sales team to a role as a Business Analyst.
A problem I encountered on the first day in my new career was when I was asked to attend my first "Agile" project meeting. Everyone assumed I was familiar with how an Agile project worked but at that time it was something I knew nothing about. So I had to bluff my way through meetings for the first few weeks before it all started to make sense.
Unless you have been involved in an Agile project before, it can be difficult to piece all the parts together. The reason I decided to write this article is because a lot of people I have spoken to are involved in Agile projects on a small and infrequent basis. Therefore, they don't need to be an expert in the end to end Agile process. However, an understanding of the general principles is extremely beneficial.
This is a very high-level overview of Agile and should tell you everything you need to make sense of all the jargon and process without overwhelming you.
What is an agile project?
The first thing to do is explain what an Agile Project is.
In the past, most projects were run using a Waterfall process. This is where a project runs through various predetermined stages and often ends with all the results delivering in one big batch at the end. This kind of process is perfect for projects such as building a nuclear power station or football stadium where you need one fully working building with an exact set of requirements delivered on a specific date. Due to this, Waterfall Projects tend to be very document and process heavy. They will have things like Benefit and Communication logs and, Risk and Issue Registers, all of which take a lot of time to keep up to date.
Agile, on the other hand, is nimbler and more iterative in its approach. This means that the project will deliver benefits little and often. This allows the Client to use new features in a short space of time while the next set of Requirements are being worked on. This is often great for the Client, as they haven't got to wait months or years to see any change. It also gives the opportunity for feedback, which can help to shape future improvements.
At this point, I should point out that Agile is a process, and not a methodology. In fact, you could probably think of it more as a philosophy. It is not a set of principles or rules, but a way of thinking. That being said, there are specific Agile frameworks which have a strict structure.
Scrum
The best-known Agile framework is called Scrum which, at its core, uses a technique called Sprints.
A Sprint is a short period of time when a team will work to deliver an agreed set of Requirements. A Sprint normally lasts between two and four weeks, and then starts all over again. For example, if a Sprint lasts three weeks, at the end of the third week, a number of new features would be available for the Client to use. The following three week sprint would work on a new set of features, and so on.
A Sprint will typically be divided into five sections, which are followed in a set order (there is a sixth section although in my experience this rarely happens).
The easiest way to explain this is by outlining each stage individually.
1. Sprint Planning
At the start of each Sprint, you have to decide which Requirements need to be worked on first. Generally, the most urgent and impactful features will be prioritised. Related features may also be bundled together as it may be more efficient.
The Product Owner* will be responsible for the prioritisation, but they will need to work very closely with the Development Team** who will advise on how much work they can get done in the time available.
*Product owner is the link between the Development Team and the people who will be using the new features.
**Development Team is responsible for making the changes, e.g. coding software.
2. Development of the new features
This stage is when the actual work is done to make the changes that were added to the Sprint from Stage 1.
The Development Stage often includes daily Scrum meetings (also known as Daily Stand Ups).
These Daily Scrum Meetings provide an opportunity for everyone involved to give feedback on what they were working on yesterday and what they will be working on over the next few days, as well as highlighting any blockers.
3. Testing
This is a really important stage that sometimes gets overlooked. It's great to have new features, but if they don't work properly, or cause unforeseen problems to existing functionality, the whole project can be impacted.
The testing involves, not only checking the new features, but making sure that bugs haven't inadvertently been created.
4. Sprint Review
Once all the testing is complete, the new features are presented to the Product Owner. The purpose of this stage is to make sure that all the changes made will meet the requirements of the business. If there are any problems they can either be quickly fixed or postponed to a later date.
5. Release
Once the new features are ready, they are generally released to the Client at the same time. This is often called "Go Live". The exact mechanics of the Go Live varies from one project to another, but it should always include communication to all the Stakeholders.
6. Retrospective Meeting
I mentioned earlier that there is a sixth stage that often gets overlooked - the Retrospective Meeting. This involves a discussion of the Sprint that just ended. The objective of this meeting is to look at what went well and what went badly (so you avoid making the same mistakes again). Personally, I'm not sure how useful this is. The Daily Scrum meetings normally take care of this, and if communication within the team is good, then this retrospective review should be happening throughout the project, not just at the end of a Sprint.
Other Activities
There will be activities going on outside of the Sprint. The most important is the Requirements Gathering. With Agile projects, Requirements will get identified throughout the Project (unlike Waterfall where they tend to get identified all in one go towards the beginning).
The Requirements Gathering process involves working with the Client or Users, and the Product Owner to determine what new features are needed. These are then written up in detail and added to a list called the Product Backlog. The Backlog is basically a to do list of the Requirements that have not yet been developed. The Product Backlog is used during the Sprint Planning stage and is the responsibility of the Product Owner to maintain.
Final Thoughts
I hope I have shown you that the principles of a Sprint are very simple. That being said, these principles are so dynamic and effective that many of the concepts can be used in every day business. For example, I have frequently used the Daily Stand Up meeting technique in projects that have not involved a Sprint. You can take any of these techniques and adapt them to your specific needs. All you then need to do is package them up into a neat framework, give it a fancy name and you've created a new methodology !