Agile: The Basics
Note: There are lots of information available on this topic on internet but I hardly find an article which gives an overview of Agile in a single post. Furthermore there are many articles which are written in a technical language and it is difficult to understand for a non-technical person. This inspired me to write the below article.
Who should read this article: Anyone who wants to learn the basics of Agile and have heard about the terms like Sprint, Scrums, User Stories, etc. but doesn’t know what exactly these terms means.
Before we start, let me clarify the meaning of Users and Customers in Agile. Users are the one who uses the product or services and Customers are the one who wants to create this product or services for the users. For example if HR wants to create an app to digitalise the reimbursement process and accordingly have given the request to the Development Team. The Customer here for the Development Team, is the HR Team and the Users are the Employees. This definition is from the perspective of Development Team / Department as Agile focuses more on the development process. Whoever approaches the Development Team, they become the Customer and together they create a software / app for the users.
Agile or Agile Software Development or Agile SDLC or Agile Methodology is a practice which is being use by software development companies to build software. Agile was introduced in the spring of 2000, when a group of 17 software developers met to discuss how they could speed up development times in order to bring new software to market faster. Earlier to this, organisations were using Waterfall Methodology. To better understand Agile, we need to first understand what is a Waterfall Methodology and why there was a need for a new methodology.
The Waterfall Method
The waterfall methodology generally consist of 5 stages, starts with the Requirements Gathering and end with Maintenance. Each phase must be completed before the next phase can start and there is no overlapping in the phases. It basically flows in linear sequential way. As you can see in the image above, the Verification (Testing) phase starts only after the Implementation (Development) phase is completed.
Due to this very nature of Waterfall Methodology, it is very difficult to change course in between. Like for example technology is very dynamics, one technology can get outdated in a matter of time. Adobe Flash is so yesterday now, which was once the market leader for streaming audio and video.
To elaborate, let me give you an example of Mobile OS. Google and Apple provide updates to their OS every often with new features and security. Now suppose you are building an iOS app for a customer and have signed a Contract wherein both the parties have agreed upon the technology to be used, the timeline, the cost and other stuffs. The Contract also mentioned that the app will be in accordance with iOS 13 and accordingly the Requirement Document has been created.
The Development Phase get started and the team has completed 40% of the work in just couple of months. And Bang… iOS 14 is announced with its most awaited feature and it is creating a buzz in the market. Your customer want this feature to be implemented in the app. Now as you are using waterfall methodology you will not be able to implement that said feature in the app because this change in iOS version has not be documented in Contract or in the Requirement Document. If the customer insist, you will need to go back to the Requirement Document Phase and start over again with negotiating on the technology to be used, the timeline, the cost and other stuffs, which will extend the timeline of the project delivery.
This is just an example to explain the process and why it is difficult to change course in between. Changing course is possible in waterfall methodology but that will cost additional time and money to the customer and if the timeline is increased the customer might lose business to the competitors.
The rise of Agile
Frustrated with this linear sequential software development process, 17 software developers, including Martin Fowler, Jim Highsmith, Jon Kern, Jeff Sutherland, Ken Schwaber, and Bob Martin met in Oregon to discuss how they could speed up the development time in order to bring new software to market faster. They later published “The Agile Manifesto” which consist of 4 Values and 12 Principles on how Agile software development should take place.
Representatives from Extreme Programming (XP), SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes were brought together for the meeting.
Agile Values and Principles
4 Values
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
12 Principles
Agile Methodologies
Now you might ask what is SCRUM, Kanban, XP. These are generally called as Agile methods / methodologies, some also call them tools. They consider “The Agile Manifesto” and then they demonstrate it in their own way or we can say that all these methodologies have “The Agile Manifesto” as their base. Explaining each of these methodologies will unnecessary make this article huge and they all deserve a separate article. I will soon come up with articles on each of these. In this article I only want to focus on Agile which is the base for all these methodologies because I believe if the understanding of base is clear you can easily learn other methodologies.
Artifacts of Agile
- Backlog: It is a prioritised list of deliverables (such as Features / User Stories, Tasks or Subtasks) that should be implemented as a part of a project or product development. It’s a decision-making artifact that helps in estimation, refinement, and prioritising everything you might want to complete in future.
- Iterations / Sprints: An Iteration / Sprint is a set period of time during which specific work has to be completed and it should be shippable.
- Requirement Document / PRD: Requirements Document is used to communicate the aims of a project in a clear, concise way to ensure all stakeholders are on the same page.
The agility of Agile
Agile means the ability to change course swiftly and seamlessly. To achieve this agility we will need to break the Goal (the software or the app) into small units. For Development we should break Initiatives (Goal) into Epics (Features), Epics into User Stories and User Stories into Tasks and Subtasks. All these features, task and subtask along with its prioritise are placed in the Backlogs. Figure below.
The development team pick some high prioritise User Stories from the Backlog and complete it within the Sprint (which is usually 2 to 4 weeks) and the most important part is that at the end of Sprint, it should be shippable. Upon call from Customer this shippable unit can be released to the users. Doing so, we have released a small part of our Bigger Goal into the market. As the users start using our product, we will start getting feedback and we can check whether or not we are on the right track. If we get the desirable outcome of the output we did a great job but if we didn’t, we have learned a lesson and will accordingly change our future course of actions.
Agile is basically a philosophy, and its hallmark are speed to market, rapid feedback and continuous improvement. So I can say the team is being Agile if it changes its priorities based on the learnings.
If Agile is being practice, every artifacts needs to be agile. From Requirement Document to Backlog to Standup . In Agile, Requirement Document are not treated as something written on rocks, it is flexible and gets updated with new learnings or new requirements. It should be created during the initial stage of the process and within a Sprint or two.
“Agile is not a framework, Agile is a mindset.”
Let us see how Agile can help us with the earlier example of iOS.
The 3rd Value of Agile says “Customer Collaboration Over Contract Negotiation”. What it means is that we should collaborate with customer rather than focusing more on negotiating the contract. If the customer wants the feature to be added, we should first focus on changing our course of action and then work on the negotiation part.
The 4th Value of Agile says “Responding to Change Over Following a Plan”. What it means is that the process should be flexible enough to accommodate the changes arise due to uncontrolled context rather than strictly sticking to the plan. The uncontrolled context in the example was the launch of iOS 14.
Now, in our example we completed 40% of development work and the customer wants to add the latest feature. Following Agile practise by now we must have deliver a good number of features and other feature would have been in the backlog. On agreement of adding the latest feature by the customer, we will add that into our backlog and accordingly will prioritise it. This become possible because Agile gives us agility or flexibility to change our course of action in between unlike waterfall model where we have to strictly follow the plan given on the Requirement Document.
Practically, the customer will have a meeting with the PO (Product Owner) and will discuss about the latest feature and accordingly will decide the priority of it in the backlog. They will also come to an agreement about the timeline, cost and other stuffs. If it cost more, the customer has the option to remove any of the non-importance feature from the backlog, which seems important while creating the Requirement Document.
Future of Agile
According to a new study by Organize Agile, 50% of the companies globally has started practicing Agile methodology and most of them have started recently. There is definitely an upward trend in practising Agile Methodology and I think sooner or later every company will understand the values of Agile and will start practising it.
Enterprises are also keen in understand how they can scale Agile for large production and hence there are new framework which has come into picture such as SAFe, Large-scale Scrum (LeSS), Disciplined Agile Delivery (DAD), Nexus and others.
Pinch of Salt
Agile is efficient than waterfall and gives lots of flexibility however there are some drawback of it.
- The high degree of customer involvement may present problems for some clients who may not have the time or interest in this type of participation.
- An Agile approach may also require some level of organisational transformation to make it successful.
Conclusion
As said Agile is a mindset and it is driven by values and principles. Scrum, XP, Kanban and other methodologies have taken this values & principles and created their own working framework. You will find most of the Agile organisations are using Scrum as their development framework. If you want to see Agile at work, your next stop should be to learn about Scrum or other Agile methodology.
Hope I was able to explain it, feedbacks are greatly appreciated.
Email: bikash.joshi@live.com Twitter @Bikash_Designer
