Hello folks,
Today, we will be discussing the processes that every software engineer should be aware of, in the world of agile software development. Also, this can be a useful guide if you are a new engineer or an engineer from a non-agile background. We will try to discuss the important yet boring processes that are playing a crucial role in increasing the number of meetings in the engineers day to day work.
Agile
Most of the product development life cycles happening nowadays are using agile methodology. What is agile methodology? At the core, the agile methodology focuses on building the product in parts, feature by feature, and delivering them in multiple stages. Almost opposite of this would be the waterfall methodology which focuses on delivering the product end to end completely without multiple iterations or changes in the requirement.
Earlier, the waterfall methodologies were used majorly. But rapidly changing technologies and customer demands have forced software development to move towards the agile way of working. This is very suitable for working on frequently changing requirements with quicker deliveries.
In this article, we will try to walk through the whole agile process from scratch considering the requirement of building a product.
Requirements
We will try to start with the agile methodology by considering a real-world scenario. Assume we have got a requirement from a person to build a messenger which is nothing other than WhatsApp. Now the person who has given this requirement will be our client for whom we will build the product and he/she/they will be paying us the money in return.
What next?
Now we need to plan a team comprising of developers and testers to build this product. But there has to be a person who can talk to the client on a regular basis to discuss the features, improvements, changes, and progress of the product. So this person can be called a point of contact for the client. Let us give a fancy name to the person Product Owner (PO). Yes, you may have heard it a lot of times.
The requirements to build or modify some product features may not always need to come from the client. The requirements may flow from different directions such as end-users (customers), feature bugs, suggestions within the organization, etc.
The product owner would talk to the client and get the requirements. Also, the clients in most cases will not have technical knowledge. The requirement which comes will not be usually clear. PO will try to transform these abstract ideas into detailed descriptions so that both technical and non-technical people will be able to understand them. In many organizations, there will be a person called Business Analyst (BA), who will handle this.
Why? If the product and requirements are huge and complex, everything cannot be managed well by the Product owners. In such cases, you would require BAs who can clearly write the details of the requirements, acceptance criteria, and other implementation details.
Acceptance criteria is a set of end goals that have to be met in order to confirm that the requirement mentioned is done (also called definition of done). It can be present in the form of a word document or in Jira.
Breaking down the product
Now that the overall requirements of Whatsapp messenger are clear to the Product Owner, the team can start working on building the product. But we are not yet there. The end-to-end completion of requirements may take up to 2 years of time. The client may not spend money and wait for the next 2 years to release it to the customers. The client may expect the product to be released to the customers in the next 3 months.
At this point, it is clearly known to us that we may not be able to complete all the features of 2 years in 3 months, we will have to identify the crucial functionalities and features which the product requires to release to the customers as early as possible. This is called a Minimum Viable Product (MVP).
For a messenger like Whatsapp, the MVP functionality might be
- add a phone number to the Whatsapp
- ability to send messages to other mobile numbers
- provision to add profile details
- to store the history of messages
- secure way of communication
The MVP design functionalities given above are for demo purposes only. Remember, MVP is not only about building it fast due to time crunch. But also the functionalities which would be added in the future will depend on the feedback received for the initial versions. It is a continuous feedback loop in which the product keeps improving.
What about the other features such as
- ability to send media, and voice messages
- create a group of multiple people
- react to a message
- delete the sent messages
- add Whatsapp status
- Whatsapp web to access outside application
These are also the items to be considered but not immediately for the initial releases. Each of these items is called a Story.
Now to execute/implement these Stories we would require a plan.
SCRUM
One of the famous strategies to execute these stories is SCRUM. Scrum is nothing but a process/framework for developing, delivering, and managing products in a complex environment.
Now that we have the stories with us (either in MVP or others for later releases), we need to start working on those. In Scrum, usually, 2 weeks development cycles are created. This is called a Sprint.
Why Sprint is even needed? With sprint in place, we can plan the tasks for the next 2 weeks and target to complete them by the end. So the planning, execution, and delivery will happen in a regular disciplined manner.
The stories which we want to work on will be picked at the start of the sprint. This is called a Sprint planning meeting in which the sprint tasks are discussed and groomed.
In a sprint out of the above-mentioned functionalities, we might be able to pick 2 to 3 stories (just as an example). These are added to the sprint. All the other stories are called backlogs (stories that are yet to be done in coming sprints). The backlogs are sorted by priority.
The development and testing team will then try to estimate the efforts required to achieve those stories and add the complexity. The complexity of a story can vary from simple to complex. The story points (a measure of complexity) are usually given in terms of Fibonacci values i.e 1, 2, 3, 5, 8, 13, 21. A simple story can be given the lowest complexity and the one which is very complex may carry story points of 21 (defined by the team).
What should be the highest story points that any story in a sprint can have will be decided by the Scrum Master
A Scrum Master is that person who is managing the scrum processes for the team. And anyone in the project can take up this role. Most companies have a dedicated person for this purpose.
Generally, in many companies, the Engineering Manager (EM) plays the role of an SM. A scrum master dedicated to just running the scrum process will not be of great use to the team/company. Hence, companies prefer an engineering manager to take the responsibility of managing the technical and scrum processes together.
Engineering Manager is not just a people manager. An engineering manager is responsible for ensuring that key projects and engineering duties are fulfilled along with solving the engineering challenges in the project.
As a part of the scrum, there has to be a daily meeting to update the status of the stories. This meeting is popularly known as "Daily standup". The words used literally mean it. All the people of the team will come to a meeting room and stand up while giving their updates. This meeting is also called a Scrum Call.
What happens in this meeting? Everyone will have to share their updates generally in the below format
- What did I work on yesterday?
- What am I working on today?
- What issues are blocking me?
After completion of 1st week, the sprint review takes place. Here we will analyze the status of the stories and tasks again. This meeting is more of a discussion on aligning the sprint to take ahead and complete as planned as well as to have a walk-through of the work completed in the 1st half of the sprint.
In the 2nd half of the sprint i.e 2nd week, the team will try to target the stories towards completion. For developers and testers, this mainly involves testing the implementation, raising the defects, fixing them, and getting it ready for deployment.
Assuming everything went as expected, the new development/progress done towards the product will either be released to the customers or shared with the client. The sprint will conclude with a Sprint retrospective meeting.
Sprint retro is a meeting that involves a discussion on how did the overall sprint execute, what went right during the sprint, what could be improved and how we could have done it differently to make things efficient for the future.
Takeaway
Now that we have understood the flow of the development process in agile methodology, it should be clear to us about the different roles which have come into existence such as SM, EM, BA, and PO.
The processes mentioned may not be exactly the same in all the companies. Development teams may prefer the modification in the scrum process which works best for them. Though these are some kind of the commonly followed guidelines, at the end of the day the process that yields the best results will only be preferred.
This article may just serve the purpose of introducing the processes at a high level. There are well-written articles and guides on the Agile processes which you can find over the web. Next time you hear about Agile or Scrum, hope you will not be puzzled.
Oldest comments (0)