DEV Community

Cover image for Clear and Effective Communication with Agile Software Development
Laura Lindeman for Salesforce Engineering

Posted on • Originally published at Medium

Clear and Effective Communication with Agile Software Development

by Rafay Syed

I was first exposed to agile software development in my first job as 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.

My third day on the job, I was involved in something known as a standup, which I had never heard of. 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 so that there are no holes or gaps in understanding across the team. They also allow 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 the idea of user stories, where each story is a task assigned to someone. To write a user story, you can follow these four steps:

  1. Define your end user.
  2. Specify what they want.
  3. Describe the benefit.
  4. Add acceptance criteria.

I learned that a user story explains exactly what the end user wants 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 customer-centricity 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. Both of my jobs so far have had teams that worked in two-week sprints. This means we are given two weeks 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 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. This occurs a few days before a sprint ends, allowing for transparency and letting everyone on the team see the progress of each user story in that sprint and prioritizing tasks accordingly. 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 and what could have been improved, adds action items to make those improvements, and gives 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 a very beneficial, productive, and efficient approach to building great software.

Top comments (0)