Agile and Scrum Methodology
Learn the life cycle of a developer
“Remember: it’s not the documentation that needs to be kept in sync, but the people.” — George Dinwiddie
As a software engineer, we work as a team to develop a product requested by client. Back then, client request application to us, and then we design, develop, test, and done. If client want some changes, we must build the application from scratch again. Of course this would take a lot of time, because software development environment is very dynamic. We will always find changes in our daily work. That’s why, we as software engineer use Agile Methodology.
What Is Agile?
Based on wrike.com, Agile is a project management methodology characterized by building products using short cycles of work that allow for rapid production and constant revision. With Agile, the software we made won’t out-of-date when done. Agility from Agile is :
- Responsive to all changes
- Effective communication across all stakeholders
- Client involvement
- The team in the organization can work well
- Rapid, the delivery is incremental
Agile process is driven by customer description, the plan is short-lived, develop software iteratively, and adapt from changes. Based on Kent Beck, the better way to implement manifesto for Agile is :
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile methodology have some principles to follow, i.e. :
- Number one priority is to satisfy the customer
- Welcome changing requirements, even late in development
- Deliver working software frequently
- Business people and developers works together on daily basis throughtout the project
- Build projects around motivated individuals
- The most efficient and effective method of communication is face-to-face conversation
- Working software is the primary measure of progress
- Agile processes promote sustainable development
- Continuous attention to technical excellence and good design enhances agility
- Simplicity is essential
- The best architectures, requirements, and designs emerge from self-organizing teams
- At regular intervals, the team reflects on how to become more effective.
On Agile, there is some implementation, such as Extreme Programming and Scrum. We usually use scrum as the product management methodology.
What Is Scrum?
Based on wrike.com, Scrum is a product management methodology in which a small team is led by a Scrum Master, whose main job is to clear away all obstacles to completing work. Work is done in short cycles called sprints, but the team meets daily to discuss current tasks and roadblocks. In Scrum, there are 3 roles :
- Product Owner — The one who represent the owner of the product (client) that being developed. Product Owner translate client’s request to a form the developer understands. Product Owner becomes a resource if the developer has questions about the application.
- Scrum Master — The one who guide the team to work according to the scrum guide. Scrum master observes, and evaluates the results of the previous sprint for further improvement.
- Development Team — The one who codes and work on the application.
In Scrum, there are 4 phases that we as a Scrum team go through :
- Initiation phase
In initiation phase, first we should make a Project Vision. Project Vision contain our vision, goals, and initiatives. In Project Vision, we tell what we will release (feature) in each sprint. Second, we make Epic(s). Epic is a big chunk of work (or features) which can be divided into smaller feature. Epic can be spread across the sprints.
The smaller feature is the one we called Product Backlog (or user stories). Product Backlog is elaborate from Epics, and defined asAs a [_SUBJECT_] I want to be able to [_WHAT_], So I can [_WHY_]
. Here’s Product Backlog example that my team use :
- Sprint Planning
There are some steps in sprint planning. First, choose PBI(s) your team will be implemented in the current sprint. Make sure all team members understand what is the PBI’s target. Second, define a story point on each PBI with poker play planning. You can use online tools like this to do it. All team members will vote on their own, and the most extreme vote (the smallest or the biggest one) will give the explanation about their choice. After that, choose the story point by majority vote. Repeat the poker play planning for all PBI(s) in the current sprint.
Next step is, Product Owner will list all the PBI(s) sorted by the story point and priority. If there is a PBI that have a story point that is too big (which means a really difficult task), just ignore the PBI. And then, for each PBI create a schema database if needed. Make sure the all team members understand how to work on this PBI.
After that, divide every PBI into smaller sub-tasks that independent, and relatively can be done on one daily meeting. If your team use Gitlab, list that sub-tasks into Gitlab board. Your team members will pick one sub-task during the end of sprint planning. Here’s the example of Gitlab board my team use.
- Sprint
It is time for the development team to code. One sprint usually takes 1–4 weeks. Every weeks, at least you should have 2 daily standup meeting (or 6 times/sprint). In daily standup meeting, every team members inform their progress, their obstacles, and their goals for next daily standup meeting. Also, each team members should have a merge request from their branch. After that, Scrum Master will update the scrum board based on the report of team members. Note that every merge request should close an issue in Gitlab. Here’s the example from my team project.
- Sprint Review and Sprint Retrospective
Sprint Review is a process where development team present the working software (releasable). In Sprint Review, the development team make a demonstration based on User Acceptance Testing (UAT). If all the test in UAT passed, then the application is ready for release. Note that user only want a 100% working product, so we have to make sure the software is ready to use, which means we can’t let any “console.log” during our debugging is shown. If the product doesn’t meet client criteria, development team should working on it in the next sprint.
Last but not least, we should do Sprint Retrospective at the end of a sprint. Sprint Retrospective is a meeting where the development team discuss about current sprint evaluation. What is good from this sprint? What do you think is bad from this sprint? What can be improved in this sprint? You can start by answering those questions. Note that we shouldn’t bring any technical stuff in Sprint Retrospective, but we should evaluate our team performance.
Agile And Scrum On My Team Project
In my Software Engineering Projects course, we have a total four sprints, with each sprint takes 3 weeks. At the end of the sprint, my team will report to the client about our deliverable product. By doing that, the client won’t have to wait until the product is done to give us some reviews.
We also do standup meeting twice a week, that is on Monday and Friday. The standup meeting usually last about 30 minutes where our team members giving their own report. We also make sure that no one on our team work on their own, which means they won’t burden themselves. We always help each other to face troubles, because collaboration is one of the main values of Agile.
At the end of a sprint, after sprint review is done, we always do sprint retrospective, where all of our team members tell what they think about current sprint. We also discuss how to improve our sprint process, so our team can be better.
That is all I can write about Agile and Scrum. I hope this article can help you to understand Agile and Scrum process in software development. Thanks for reading!
References :
- What Is Agile Methodology in Project Management? (wrike.com)
- Here’s what Subject experts say about an Epic in Agile (knowledgehut.com)
- Sprint Planning slides by Software Engineering Projects, Computer Science Faculty at University of Indonesia
- Scrum Guide by Software Engineering Projects, Computer Science Faculty at University of Indonesia
- Agile Methodology slides by Software Engineering course, Computer Science Faculty at University of Indonesia