Extended Agile Software Development — Part 1

Welcome to our first blog post. Please feel free to drop your comments below for asking questions or add knowledge to this guide.

Extended agile methodology, according to our definition is, uses agile methodologies combined with a strict set of rules for the processes of such methodologies to achieve better productivity and efficiency. Undoubtedly, there are many agile methodology guidelines that can conflict with ours. However, this guideline has taken shape with eight years of experience in real-life scenarios and continues to develop by overcoming bottlenecks during the processes and adding new rules to overcome newer problems.

To fully comprehend this guideline, some basic knowledge about, including but not limited to, GitFlow, Pull Requests, Code review, Unit tests, CI/CD are required. These topics will be explained briefly before mentioning them. You can learn more about those in detail by reading our upcoming posts or researching on the Internet.

This is the first part to explain how to reach ultimate Agile processes with integrated rules and points. We will try to cover different perspectives of Agile team members in upcoming writings; Developers, analysts, testers, product owner.

Firstly, the main focus will be on general aspects and how Agile methodology works, briefly. In our next blog, we will focus on the developer’s point of view during the processes. Let’s start with some keynotes;

Team: Agile team members have different roles who are responsible for successful sprint completion.

Photo by Lala Azili from Unsplash

Like in a sports team every position can require different skill sets or job titles in Agile. We should not only think of developers as an Agile team. Agile team should be considered as a team that can live and develop an app by itself.

• Developers are responsible for writing the code for the application. We can combine all sorts of developers to this section such as Backend developers, Full-stack developers, Front-end developers, iOS or Android developers, etc. We also consider other technical roles in this title such as Application Architectures, DevOps, DB Admins, etc.
• Testers are responsible for ensuring the written code fulfills the requirements of the application and detecting bugs. In some teams, testers are also responsible for writing test codes such as Test Automation, UI Tests, Stress Tests, etc. to increase the quality of the application. Testers should also report missing parts on the user experience side. In addition, they should monitor the errors received by the users using the live application through analytical tools and evaluate errors according to their priority.
• Analysts are responsible for writing the analysis report which is used by the developer to code the requirements (features) and by the tester to create test cases and verify that the written codes are cover the analysis report. Analysts are also can be considered Scrum Masters for the team. Analysts and Analysis documentation are vital to reflect customer needs with technical understanding. The analysis report is different than software requirement documentation and defines application flows by covering all conditional cases without missing any points about the feature or new requirement.
• UX/UI Designers are responsible for creating visual interfaces or perspectives to the applications and flows to make responsive, user-friendly, and good-looking apps. Having a UX/UI designer in the scrum team is not mandatory but it is recommended.
• Scrum Master is a person who orchestrates the sprint to reach success. This person can either always be the same or can be changed any time by choice. This person can also be a developer but is usually selected among testers or analysts. This role has vital responsibilities such as supporting each team member and clearing obstacles in the path during the sprint days. Meetings are also managed and controlled by the scrum master.
• PO or Product Owner is usually one person who communicates with app users or customers to obtain their needs or wishes. They are also responsible to track new technologies to draw a roadmap to the application aka the product. After taking the needs from the customers, PO should transmit those needs to the Analysts for generated related analysis reports which can be used afterward for implementation. Product Owners usually attend the Sprint planning and Refinement meetings only and they are not the core unit on the Scrum Team.

Sprint: Duration of a time where taken tasks should be started and completed by the scrum team members.

Sprint represents a fixed repeated timeline for the scrum team. In this period, each job should be started and ends before the sprint ends. Tasks can be development, testing, documentation, or other things like meetings, job interviews for the technical leaders, demonstration to the customers, etc. It is important to reflect all these tasks to the sprint plan to avoid misplanning. Usually, the duration of the sprint should be between 2 weeks to a month. To complete the sprint successfully, the commitments should be fulfilled by the team during the agreed duration of the sprint. All team members are responsible for having a successful sprint. For the next sections when we talk about sprint duration it is 2 weeks.

Meetings: “Hearth Rate Monitors” of the sprint.

There are fixed meetings in Scrum methodology. Those meetings are required to guide the team and organize the Sprint status.

• Daily meetings — Standup meetings are the meetings that are executed each day to check the status of the sprint plan. In this meeting, each team member explains what has been done on the previous day, what will be made today, and concerns or problems if there are any. It is recommended to have this meeting in the early morning like 09:05 before starting the tasks. This shouldn’t be a long meeting and every person should not speak for more than 2–3 minutes. Scrum masters lead this meeting by permitting people to speak in alphabetical order according to their name. In a recommended way, all scrum team members should attend and talk about their tasks in this meeting. At the end of the meeting, Burndown Chart can be used to check the status of the sprint.

• Sprint refinement meeting is a meeting that occurs only one time in the middle of the sprint. Let’s say if our Sprint starts on Monday after the planning meeting, this refinement meeting occurs next Monday. In a refinement meeting, we adjust the ongoing sprint plan because the priority of tasks may change over time due to the customers’ needs. If no priority changes occur, then adjustment may not be required. This meeting is also important to pre-adjust future sprint tasks. If some information is missing about the task that will be taken in the upcoming sprint, there can be small talks about clearing the missing information with external participants. This refinement meeting can be done with a small group of persons including the product owner, analysts, technical leads, and some testers.
• The sprint planning meeting is a meeting that members plan the next sprint, which occurs on the first day of the sprint. These planning meetings are crucial for team commitment. If the capability or velocity of the team overflows by the new tasks, then commitments may not be completed or overtimes are required. If lots of free time is given to the team after planning, then customer requests may not be fulfilled at a time. So, the best way is not to overflow or underflow the total task weight. The recommended way to weigh tasks is using Fibonacci story points. By considering one day as 5.5 points, for a person sprint is 55 points (for a two-week sprint), members estimate the tasks by considering all the task’s aspects such as reviewing, testing, coding for the development. This is a challenge that requires attention because estimating a new task requires previous experiences and skills that need to be compared against previous tasks. Also, the estimation can vary by the task owner’s experience, domain knowledge, and project know-how. For example, junior team members may require more time than senior team members to complete this challenge. Our recommendation here is to assign each sub-task to team members before giving the story point. Moreover that, breaking the tasks into sub-elements can give the advantage of seeing the sub-modules or sub-tasks and have advantages for evaluating the story point. The weighting phase may vary depending on the dynamics of the teams. The key point here is to score the task independently of the individual, but not to ignore the team’s talents.
• Sprint ending meeting — Sprint evaluation/review is a meeting that is done just before the planning meeting for the next sprint to close the current sprint. By comparing the work logs and estimations, the overall success of the estimates can be calculated. This is very important because in each sprint cycle you want to increase your estimation precision to give more accurate story points to eliminate overflow or underflow situations.
• A retrospective meeting is a meeting that is used to evaluate the previous sprint process. It can be used to speak about process bottlenecks or the problems that the team had during the sprint. This is a free speech zone where every team member can express themselves and his feelings openly. If there were problems in the sprint, they should be addressed in this meeting. Each meeting should be recorded or documented by asking what did the team do well and in what way they would have done better. Getting answers from everyone is important. This will give the advantage to see how the process improves over sprints by answering the following questions; Are we making the same mistakes? Did we overcome the issues that we had previously? Do our team members get happier over the period? So to find those answers, we ask the following questions in each retrospective meeting;
• What did we make good in this sprint?
• What processes should we improve?
• Action items
• Happiness / Stress points over 10 and how they are feeling about the sprint.

Kanban Board: Columns to track jobs status.

Kanban board is used to track a task’s status in a table view. There are many tools to manage your Kanban board like Jira, GitLab, Trello, Asana, etc. If you do not want to use the software you can use stick notes and pen too :). However, to apply rules to your processes, you should stick to the software that allows defining those rules. We recommend having 5 columns as follows; To Do, In Progress (aka Work in Progress or WIP), In Review, Testing, Done. Each column shows the state of the task.

Photo by İrfan Simsar from Unsplash

• To Do column is used to show a task that is not yet started. Hence, the assignee person can be changed since work is not yet started.
• In Progress column shows that the task is currently active. The assignee is currently working on that task and the task should not be transferred to another person. Also, there can be some changes for the development phase since it is not yet ready to review. We recommend opening a pull request for the branch related to the coding task with the title format: [DRAFT] or [WIP] <Task Name>. Development should be done by looking at the analysis report that is generated for the task.
• In Review, a column is used to describe the task is done from the perspective of the assignee and ready to be reviewed by other team members. However, this is not testing. If the task is a coding task, reviewers should control the general coding standards, check if the code is clear to understand, if the assignee stuck to the agreed software architecture, and wrote sufficient unit tests, etc. We will also add a blog post about the code review checklist since it is very detailed on its own. If the task is an analysis task, the report should be reviewed to see if there are any missing cases and clear to understand. “Review is done” state can only be achieved when all technical reviewers of the pull request have approved.
• Testing column is used to describe a task that is ready for testing and should be assigned to one of the testers in the team once it is moved to this column. The tester should check if all technical members approved the pull request before testing the task. If all is approved then it is ready to test, otherwise, it can be assigned to the developer again. In this section, the tester should control the changes with test cases that are generated from the analysis report. Test engineers should approve the task not only by looking if it’s bug-free or not but also by checking if code changes satisfy the analysis report. This can be considered as verification & validation. If all is okay from the tester’s perspective, the task assignee is changed to the analyst, a comment should be added to the task detail about the testing process that took place specific to this task, and then approval is given to the pull request by the tester (We will tell why testers are also approve pull requests in our upcoming writings). This means that the task is ready to merge by the analyst. If the analyst knows that this task will be released in the upcoming release package, she/he also approves the pull request and clicks on the merge button. Since the task is merged the related package information should be added to the task by the analyst and moved to the Done column.
• Done column is used to understand the task is done and should not be worked on it anymore in this sprint. It may be merged to the package by the analyst if this coding task will be available in the next release. For the soft tasks, the analysis report should be attached and finalized.

That’s it for Part 1 of Extended Agile Software Development. Some parts may not be fully comprehended but with the following parts, we will try to get rid of this fog and show the reasons underneath with details.