Agile is a technique, method, or strategy which is used in software development as an alternative to the traditional methodology. As the name indicates, it seeks to make software development easier and manageable; by implying agile, the team can observe the overall progress of the project development and make better decisions, “User Story, Burndown Chart”, make more maintainable and flexible software “Testing, Refactoring, and Pair Programming”, and produce consistently a free-of-bugs deployable product "Sprints, and Iterative Development" — by using specific practices and artifacts (the italicized text) that we will elaborate later on.
Agile has several methodologies — the prominent ones nowadays are Scrum, Extreme Programming, Lean Software, and Crystal — that follow the same principles mentioned in Agile Manifesto 2001. Accordingly, instead of a single development method (the traditional software engineering), agile provides us with a heap of methods and practices that are established and recommended by professional software engineers with a supreme experience in the field. Moreover, engineers can — and they should — combine between these methods to wind up with the best suitable plan for their project, rather than embracing a single method entirely, as if it’s a tenet!
The following two sections shall give you a satisfying overview of agile, that is neither too brief nor too verbose; since it covers the overall concepts of agile. However, you’ll find more exposition and practice guidance in “Agile!: the Good, the Hype, and the Ugly” book, by Bertrand Meyer, which is the only reference for this article.
Some Agile Terminologies
This section and the following one, could be combined into one concrete section demonstrating agile principles. Actually, the content in this section is a constituent of the following one, however, it has been segregated for demonstrative reasons. You can consider it as an introductory.
Velocity: indicates the project progress pace velocity; how many tasks are accomplished in a sprint (days). It’s used as a virtual artifact to observe the project state, and how the team is going on.
Big Upfront: it’s a derogatorily term used to refer to big steps, that usually ends up paralyzing the project’s velocity.
Sprint: it’s a definite period of time (a development iteration), after which the project should be ready for new version deployment, even with partial functionalities.
ROI: Return Of Investment. A virtual assessment of functions, to decide which functions should be implemented first.
Scenarios: it is a description of a particular interaction of a user with the system. Moreover, it’s considered as a replacement for requirements, while user interaction is definitely more suitable, than collecting requirements (Big Upfront process), in defining tasks. Scenario is a more general term that carries two artifacts: use case, and user story.
Use Case: it is a full run through the system. Observing the scenario from the beginning of starting the application, by the user, to the completion of a certain task(s).
User Story: it is a declaration of small unit of functionality expected by the users. Such as: “As a customer, I want to be able to delete my account”, “As a customer, I want to make some information in my account private”... etc.
Burndown chart: a record of a project’s velocity.
Planning Game: a group estimation techniques which ask the participants to come with initial estimates independently, then examine each other’s estimates and iterate until a consensus is reached.
Agile Principles
The principles are followed from the values, which mentioned in the manifesto, and from these principles each methodology devises its own practices and artifacts, that fulfill the principles and therefore preserve the values.
There are twelve principles mentioned in the manifesto (https://agilemanifesto.org/principles.html). In this section, we are going to discuss, separately, each principle and mention its followed practices and artifacts.
1. Continues Delivery
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Earlier, in traditional software engineering, it wasn't uncommon to split the project into sub-developments and then, at the end of the development or after few months, integrate those constituents all together to institute the whole project. This practice was effective in simplifying the development of the project, however, it was impediment for deployment. It takes much time to fix the bugs and incompatibility between different parts (sub-developments) of the system.
Therefore, agile methodologies advocate CI / CD (Continuous Integration & Continuous Delivery). The sub-developments should be integrated frequently, in order to provide two values: working software and customer collaboration. The first is accomplished, in the sense of fixing bugs and incompatibility as soon as possible, by integrating the parts after few weeks, rather than months (there are methodologies recommend doing it several times a day). Moreover, the later is accomplished by producing working software after each integration to the customer for feedback.
2. Accept Changes and Customer Role
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
In agile, the customer has a central role in the project development. Rather than documenting the requirements at the planning phase of the project — which considered as a big upfront — we let it evolves as the project develops, by giving the customer a central role that usually concerns in trying intermediate releases of the project. This approach, replacing the requirements or vanishing big upfronts, is almost applied by all agile principles.
3. Working Software
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Working software is the primary measure of progress.
These two principles may seem redundant of the first one listed in this section. However, the both demonstrates a guideline that our practices shall follow. These two principles telling us that we should always be able and ready to produce and deploy a working software (new version of the application) after each sprint, even if with partial functionality. Neither The deadline can be postponed for deployment, nor the application can be deployed with bugs, because of adding new feature to the application.
So, the primary measure of progress is not how many functionalities have been added. Working software has more priority in agile development, and the software is assured working through the use of test suites.
4. Team Meetings
Business people and developers must work together daily throughout the project.
This principle is, obviously, a practice than it’s a principle. Agile methods advocate frequent face-to-face contact between team members. It helps teams remain cohesive, know what everyone is doing, and spot problems early.
5. Open Rooms and Pair Programming
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Agile methodologies reject and revolt on cubicles and closed offices. It’s preferable to set up the office as an open room to favor constant interaction between team members. Moreover, a common practice of agile, is pair programming. In which the code is written by one developer, while being supervised or criticized by another developer. This helps catching mistakes or even bad code early.
6. Sustainable Development
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Again, another principle seems redundant; all the previous principles certainly invoke sustainability. However, it may have other meanings or values. This principle refuses putting the team in an exceptional pressure, rather, the developers should work in reasonable hours, preserving evenings and weekends. It could be considered as a revolt on managers, as we may see in later principle.
7. Refactoring and TDD
Continuous attention to technical excellence and good design enhances agility.
To make our software agile, we should create a test for every single code. Concisely, we should not write any new code before creating its unit tests. Therefore, the test comes first then we think about the simplest code that makes that test passes, and we iterate these two steps over and over again, until there is no more test to be passed. In other words, this part of the software we are working on is done. This approach is known as Test-Driven Development.
Eventually, applying TDD winds up with a fragile, messy, and miserable design of the code. And here comes another significant practice in agile, Refactoring. Which is the process of critically examining a design or implementation and applying any transformations that may be needed to improve its consistency. (It may not seem obvious, if one doesn’t know what software design & architecture is)
8. Minimalistic Funcationality
Simplicity--the art of maximizing the amount of work not done--is essential.
The development phase in agile methods should be as simple as possible, as the team must be able to deploy a new version in two weeks! Therefor, the functionalities that need to be done in the next iteration (sprint), must be essential and requested by the customer. So, if the team meeting before the beginning of any sprint “planning game”, winded up with ten functionalities whilst two of them are only essential for the user, the other eight functionalities are excluded for next iterations. It’s a matter of concern to be aware of that the ROI is definitely used in the exclusion process.
9. Self-Organizing Team
The best architectures, requirements, and designs emerge from self-organizing teams.
Agile methods redefine and limit the manager’s job by transferring many of the duties to the team as a whole, including one of the most important responsibilities: selecting tasks to be performed and assigning them to developers. Agile teams are self-organizing, deciding on their own tasks.
10. Retrospective
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Another agile practice is the retrospective, in which a team having finished a development iteration takes time off further development to reflect on the experience and the lessons learned, with the goal of improving its development process.
Top comments (3)
Thanks for the great article!
Could you maybe elaborate this? In my experience and what I've read, applying TDD improves the design. Like the Tip 69 of Pragmatic Programmer says:
Design to Test
Start thinking about testing before you write a line of code.
and Tip 66:
Testing Is Not About Finding Bugs
A test is a perspective into your code, and gives you feedback about its design, api, and coupling.
What do you think?
Hmm...
I hadn't read "The Paragmatig Programmer" before, despite reading about it from Twitter a long time ago.
I'll add it to my list.
Obviously, there are two different approaches in applying TDD. I have two references for the one I mentioned here (that leads to a messy structure of the program, and follows agile principles as well. Minimalistic and simplicity are essential in Agile Development); the first one is Meyer's book, while the second is one of Robert Martine lectures.
In "Agile! The Good, The Hype, and The Ugly" book, page 9, Meyer says:
In this TDD demo, Uncle Bob demonstrates how should we apply TDD in our projects. If you watched this demo, it definitely would be clear for you, how TDD creates code with a messy structure.
https://youtu.be/58jGpV2Cg50&t=2630s
Eventually, I'd like to share this debate between Robert Martine and Jim Coplien with you. It leads us to believe that agile proponents have a different perspective on TDD, which is the one used in this article to define TDD.
youtu.be/KtHQGs3zFAM
I hope everything is clear now.
Cheers.
Anything Agile is always a pleasure to read. The more we learn the better.
We're big fans of this subject in our team, we actually wrote an article about and we'd love your comments: zenkit.com/en/blog/agile-methodolo...