Jun 18, 2021
Agile Methodology and Scrum Framework / [Software Development Engineer in Test Article Series Part 2]
Warning: Articles may include grammatical mistakes because of my poor English.
Good news: Anyway, you will understand almost everything about our topic.
This is the second article of my “How to Become a Software Development Engineer in Test” article series. All of these articles have been written in ‘question-answer’ format. As I learned from some of my Filipino friends, this method was developed by Socrates to explain things better. So I hope the techy and non-techy guys will benefit from these articles.
You can find the first article here. It is highly recommended to read the previous article before this one.
Since I have been a software developer for more than 11 years I will provide some sample codes of real and working examples. These code samples originated from mobile applications, desktop applications, web applications, web services and various database procedures as well.
To explain things much better, Lady Q and SorBi are intensively used in my articles as samples.
Lady Q: A businesswoman and client for the SorBi app. She pays money to a software development company to have the SorBi app developed.
SorBi: An android application for creating and sharing polls. SorBi is used as an example in this article series. This app is available on Google Play and it supports English and Turkish languages.
Let’s start and enjoy learning the exciting stuff of Agile&Scrum!
Question: I have been looking forward for our exciting topic man. What are Agile and Scrum things? I am getting complicated.
Answer: Come on buddy. You need a system to work with people in collaboration. Like in every community, staff and stages involved in SDLC need a system too. So someone smart invented Waterfall Methodology and applied it to the manufacturing industry.
Q: Why are we talking about manufacturing industry?
A: Waterfall Methodology was like a revolution in factories. With the industrial revolution Waterfall Methodology contributed much to factories. It has the same steps as SDLC: (1) Requirement, (2) Design, (3) Implementation, (4) Testing, (5) Deployment, (6) Maintenance.
So some other smart guys applied Waterfall Methodology to SDLC process as it is. After a while Waterfall Methodology started to cause same problems for clients, vendors and development teams.
Q: No one is happy, ha! Why?
A: Because SDLC process is different than assembling a car in a straight line. SDLC has its own characteristics. If you implement Waterfall Methodology to SDLC you waste a lot of time for documentation. Every stage is strictly bound to each other. Like Pamukkale Travertines, the water at low level pools can not go back to upper level pools. So as the Waterfall Methodology is. You have no chance to rearrange the staff.
After a while clients lose their patience. Business Team drawn in a lot of paper work. The main concept is easily forgotten. After a quite late time Development Team publishes an app release at the end. But clients are angry with the whole process and the app itself. Because they see their app for the first time, unfortunately, this time is the end of the whole long process.
Q: Oh my Gosh! Are you kidding me?
A: Absolutely not.
Q: Are the vendors happy at the end?
A: Absolutely not, except for vendors with their last job! Put yourself at his place.
Q: As a vendor if my app is outdated or not meets the client’s needs how can I be happy with that? I am running a work man. My company must be a respected one in the IT industry. You know what? If I were Lady-Q, I would like to see my app at an earlier time to test or evaluate in terms of my needs. Poor Lady-Q. Did she lost a lot of money because of this Waterfall thing?
A: A lot of stakeholders lost billions of dollars because of Waterfall Methodology in SDLC. But do not forget that “Waterfall Methodology is still easily applicable to small projects and it is also beneficiary“. Do not worry about Lady-Q. Her app is on the beginning of the way now. The good news is, her vendor works with Agile Methodology’s implementation Scrum Framework.
Q: What does ‘implementation’ mean? You are always saying ‘implement this…, implement that…’ and so on.
A: Implementation is adapting a system/framework/blueprint/template to your needs. For example you have a master plan explaining how to build a portable house. You follow the principles of master plan with applying your requirement in a flexible manner as well. This kind of masterplans have flexible parts as they have basic parts (the skeleton). So you make an implementation of masterplan by this way. We will use the word ‘implement’ in testing and coding stages as well.
Q: Very well. By the way, what are these Agile and Scrum things? I hope Agile is much flexible, respective to clients then Waterfall.
A: Agile is just like you described. It is a mindset. Agile methodology values
- individuals and interactions over processes and tools,
- working software over comprehensive documentation,
- collaboration over contract negotiation,
- responding to change over strictly following a plan.
Q: How fascinating it is! Isn’t it?
A: So is the Scrum Framework itself. Scrum allows us to focus on delivering the highest business value in the shortest time. There is a Scrum Team along with the SDLC process.
There is a Product Owner (PO) in Scrum Team. PO mainly defines the features of the product, priotarizes the features, decides the release date and content, accepts or rejects work results (at the end of the Sprint).
There may or may not be a BA in a Scrum Team. But if you have a BA in your team, most likely he will act as an assistant of PO and helps him. PO and BA form the business people of the Scrum Team. Generally they are not technical people. PO is always the boss of the whole team and one level upper than the BA.
We have a Scrum Master (SM) in Scrum Team. SM is mainly responsible for enacting Scrum values and practices as well as removing impediments.
Scrum Team’s 3th member is Development Team and it consists of software developers and manual/automatized software testers. They develop the application by coding and testing.
Q: How does this SDLC process handled by Scrum Team?
A: First, Product Owner gathers requirements from the client, (if exist) stakeholders, domain experts, end users. PO also can examine the similar applications on the market. Eventually, Product Owner prepares the Software Requirements Specifications (SRS) Document based on the valid requests that meet the SMART (explained in the previous article) criteria. A sample requirement may be like “user should be able to visualize the counts of questionnaires divided by their category”. PO is also responsible for creating user stories and prioritizing them. A sample user story can be like “As an administrator of the SORBI poll application, I would like to be able to visualize the counts of questionnaires divided by their category as a line chart in order to make analysis”. All of the user stories are named Product Backlog (Scrum Artifact 1/3).
Q: It makes sense now. I think there must be meetings and common definitions among the team to communicate. Is the Product Backlog one of these definitions?
A: Absolutely. After creating the Product Backlog, the Scrum Team have a meeting called Sprint Planning (Scrum Meeting 1/4). In this meeting some prioritized user stories are selected for the first spring. Sprints are usually 2 to 4 weeks periods for developing the selected user stories. Selected user stories for a Sprint are called Sprint Backlog (Scrum Artifact 2/3).
Q: So good. What do they do when there is a problem about the infrastructure? Another example maybe that; one can wait for other’s work to be finished but the depending work is not finished yet. What steps to take?
A: All problems are transferred to Scrum Master (SM). These impediments are called Show Stoppers. SM’s first duty is to server the team and remove the impediments. For a good communication among team members Scrum Team have a 15-minute meeting, called Daily Scrum (Scrum Meeting 2/4), everyday at the morning. In Daily Scrum meeting, there are only three questions you have to answer as a team member; (1) What did you do yesterday? (2) What will you do today? (3) Is there anything blocking you?
If you have a specific problem, you can discuss it after the meeting in order to prevent wasting team’s time. This kind of problem is called as ‘Parking Lot Item’.
Q: What do they do at the end of the Sprint?
A: Every Sprint is like a project. At the end of the Sprint a shippable product is created and a Sprint Demo (Review) (Scrum Meeting 3/4) meeting is held.
Q: Shippable product?
A: Shippable product is a possible application release. That means, if the Product Owner decides to publish the product it will be the release (published) version of the application. The Product Owner can also decide to publish a new release after preceding Sprints.
Q: Who does attend to the Sprint Demo meeting? What is the purpose of it?
A: Customer, stakeholders, Product Owner and the whole Scrum Team attend to this meeting and a live demo of the developed functionalities/features are shown. So Lady-Q can examine her application by using it. That is one of the most powerful attributes of the Scrum Framework. Customer can hold his/her product at very early stage of the whole SDLC process. So he/she can give feedback to Product Owner. Feedbacks are also the most most powerful attributes of the Scrum Framework. With holding the product Lady-Q is very happy to see where her money goes. She is also happy to be a part of the development process with her feedbacks and welcomed new requirements.
Q: So, after the finished Sprint the new one is on the way, right?
A: Definitely. But there is one thing left, that must be done before the preceding Sprint Planning meeting. It is Sprint Retrospective (Scrum Meeting 4/4) meeting. The day after the Sprint Demo meeting is held, the Scrum Team have Sprint Retrospective meeting to evaluate the pros and cons of the last Sprint in order to enhance their productivity.
Q: How do they understand whether a Sprint goal is achieved?
A: At the Sprint Planning meeting, they define the “Definition of Done”. It is a definition of a checklist to determine whether the sprint is ended or not; like “unit tests are passed”, “code reviewed” etc.
Q: Ok. How do they follow their project scope over the Sprints?
A: The Scrum Team creates a chart called Burn-Down Chart (Scrum Artifact 3/3) to monitor the project scope creep, running the team by schedule and comparing the planned work against the team progression. This chart is a simple linear chart showing the comparison of actual effort and estimated effort.
Q: At the end of the day they must be happy because they finished the Sprint.
A: Have a look how happy they are:
[to be continued…]
Many thanks to @ratilgan for his great contributions.
You can read the next article Evaluation From Requirement to User Story here.
