Why I Love Agile Software Development
My first exposure to agile software development was when I worked at The Home Depot as a Software Engineer. Agile, for those of you who may be unaware, is a methodology that many software engineers practice when they are building software. The people involved in building software aren’t just software engineers. Product managers and engineering managers are also involved in the software development process.
One thing that really stands out with agile is that it is adaptive to the changing requirements that the customers may have. One day, the customer may want a product to contain certain features, but then that customer’s requirements may change as engineers are developing the product, so engineers can go back and modify their codebase in order to be adaptive to the customer’s changing requirements.
When it was my third day at The Home Depot (my first official day at the office), I was involved in something known as a standup. I had never heard of it. Everyone stood up, went to a corner of the office, and made a circle. This standup involved software engineers, a UX designer, a product manager and an engineering manager. Each person would spend about 30–60 seconds talking about what they worked on the day before, what they would work on during the day, and if they had any blockers. I was amazed at the level of communication that each team member was providing. And these stand-ups were known as ‘daily stand-ups’, meaning that they would happen every day and we would have them at 9:15 AM.
Stand-ups allow for effective communication amongst all team members and allow for transparency, that way there are no holes or gaps. It also allows others to jump in and help an engineer who may be struggling with completing a task. This is one key aspect I love about agile: it involves clear and effective communication.
Another concept I got exposed to was this idea of user stories, where each story is a task assigned to someone, and these stories contain these 4 key aspects:
I learned that a user story explains exactly what the end user is wanting to see in a product. User stories are mainly written by the product manager, who gathers requirements and steers the product in the right direction. The product manager is also known to represent the “true voice of the customer”. This was another aspect of agile that amazed me.
I learned another term: sprint. In agile, a sprint is the amount of time that is allocated for completing certain user stories that are grouped together. For example, there were two-week sprints with my old team at The Home Depot and even with my current team at Salesforce. This means we are given two weeks time to complete any features that are assigned for that sprint. If an engineer does not complete a story assigned for that sprint, then that story gets placed in the next sprint.
A sprint involves multiple phases, including: sprint planning, backlog grooming and retrospectives. I will go over each of these.
In sprint planning, the product manager, engineering manager, UX designers and software engineers will come together to discuss the tasks for the new sprint. What I like about sprint planning is that everyone gets perspectives on each team member’s viewpoint about the stories that would be assigned for that particular sprint. It also gives everyone an idea on what tasks are prioritized by the Product Manager and what the goal of the sprint is.
In backlog grooming, the team reviews the progress of stories that are currently being worked on as well as prioritizing stories, and this occurs about 2–3 days before a sprint ends. This allows for transparency and allows everyone on the team to see the progress of each user story in that sprint as well as knowing which tasks need to be prioritized. The stories that are prioritized at the top are the stories that are ready to be delivered.
In a retrospective, or a retro, the team discusses what went well in the sprint, what could have been improved, adding action items on making those improvements and giving kudos to people! This happens after the end of a sprint, and it is one of the most refreshing parts about agile. We each get an opportunity to celebrate our successes as well as seeing how we can improve in the next sprint.
My experience with agile has been amazing, and it can be very beneficial, productive and efficient to building great software! Later I will do a deeper dive into the world of agile! 😃
Hope you enjoyed! Thanks for reading!
