Agile? Scrum?
An individual review article for PPL UI 2020 Course
Agile?
Agile means the ability to move quickly and easily. In software development, agile is an approach that focuses on fast incremental delivery, adaptive requirement changes and team communication to improve the collaboration process. Minimum viable products (MVPs) are run through several iterations before a final one is set. It is generally said that agile is a mindset. A mindset built on the Agile Manifesto and its 12 principles.
Agile Manifesto
12 Agile Principles
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–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, then tunes and adjusts its behavior accordingly.
source: https://www.visual-paradigm.com/scrum/what-is-agile-software-development/
Scrum?
Scrum is one of the frameworks that follows the Agile mindset. The practices in Scrum are divided among roles in the team who work together to reach a well-defined goal within 2–4 weeks (Sprints). Sprints are done in iterations and comprises of the Scrum Events.
Roles in the team
- Development Team
The development team is responsible in developing the product and its value. They are self-organised to work and communicate with each other the problems encountered in order to make quick adaptive changes. - Scrum Master
The scrum master is responsible in facilitating and coaching the development team to ensure an efficient and productive Agile development. - Product Owner (PO)
The PO is the ‘bridge’ between the Scrum team and the customer. They are responsible in communicating the product values to the rest of the team and therefore requires understanding of the product vision.
Scrum Events
- Sprint Planning
Before each Sprint, a planning is done to determine the Sprint goal defined by the Product Owner and the Sprint Backlog is chosen based on that goal. Here, the stories from the backlog are broken down into tasks. Those tasks are then assigned estimation points, represented with Point Fibonacci. - Daily Scrum
These are meetings that are also known as daily stand up meetings which have the purpose of monitoring progress and enforcing transparency. Here, the development team discuss what each person has or has not done, the obstacles encountered and what each person is going to do next. - Sprint Review & Retrospective
At the end of a sprint, a review is done. Sprint Reviews will focus on assessing the working software and discussing the deliverables’ approval and acceptance from the Product Owner. Sprint Retrospectives will focus on assessing the team’s performance and the lessons learned during the sprint.
Implementation in our team
Agile Manifesto
- Individuals and Interactions
In our team, we value the members’ different strengths and how well they do in different environments. So, through, and outside of, our Daily Scrums, we discuss the difficulties we have more thoroughly instead of just mentioning them and going back to our work. - Working Software
In this first sprint, we have not delivered much working software besides having made one page that simply displays information. So far, we implemented this value by focusing on getting that page finished first before documenting. - Customer Collaboration
For this value, we did not leave out focus for communicating with other roles. We have, on several occasions, conducted meetings involving the PO, Scrum Master and the previous Team that developed the BisaGo application. From these meetings, we better understood the requirements, future goals and value of the product. - Responding to Change
So far, there wasn’t a time where there was a huge change in requirements or tasks. However, there was one time where the PO asked for a minor redesign on one of the application page and the sidebar order. Previously, our plans were to have the sidebar only contain some parts first, but we responded to the change and added the parts the PO asked for, made changes for the reordering and applied the redesign for one of the pages.
Agile Principles
(numbers refer to which principle is currently being explained)
In our work applying the principles, we keep priority of satisfying the customer by making sure our work follows the product value delivered to us (1). Any sort of requirement change that comes our way, we do our best to welcome them even if it comes near the end of the Sprint (2). An example is a design change that came from the PO during the last few days of our first Sprint, but we worked all night to implement that change since it is also our priority to deliver working software (that satisfies the customer) frequently (3).
Additionally, this leads to how we apply the principle of having working software as the primary measure of progress (7). So not only we make sure our issues/tasks are finished, but we make sure that after all the testing and merging, we have a working software. However, we also apply the art of maximising the amount of work not done. We do this by making sure all the work we do sticks to the current PBI and the task breakdown from the chosen PBIs (10). An example is for PBI Tentang Disabilitas, the goal is just create the pages that show the details of each type of disability, so we only did that but not create the navigation button to go to those pages. We created the button and redirection functions when we were doing the PBI Navigation Enhancement. For the work we actually do, we pay continuous attention to the technical excellence and make sure they have good design since we believe both factors enhances agility in our work (9).
Since we involve the PO and Scrum master quite often, we are confident that we have applied the principle of having the business people and developers work together frequently (4). We do these through meetings via Discord or Google Meets. For communication within the development team, we frequently have online (since right now, online is the closest to face-to-face) meetings, besides standup meetings, to work together and convey information (6). Since we have frequent meetings to work together and update on those we do individually, we have a fairly constant pace of work progress among the whole team (8).
Through these meetings, we make sure the task and environment is suitable for each individual and that they have the support they need. If a member feels they need any support, we do our best as a team to help, motivate, and trust them to fulfil their work (5). We do all this to promote a self-organising team since we do our best to produce the best architecture, requirements, and designs. We schedule our own work and meetings appropriate to the goal and each individuals’ strength (11). Finally, we have surely applied the principle of reflecting on how to become more effective at regular intervals through our Scrum retrospectives, this is also aside from further reflection on some of the external meetings we conduct (12).
Sprint Planning
Before our Sprint Planning, the Product Owner has provided us with the Product Backlog Items (PBI) along with the high fidelity mock up. During the meeting, we defined our sprint goal and Sprint Backlog by choosing the related PBIs. Then, we broke down our tasks and utilised gitlab to create issues corresponding to our tasks. Furthermore, we determined each task’s estimation point or weight using scrumvee.com and assigned the tasks to each member of the team. Here, is an example of the work done in the process:
Our chosen PBI
Our tasks — git issues
Weight estimation
In our first sprint, we had some confusion on the terms and just how things worked. Especially during estimating the weights of each task, the weights we gave were probably not as appropriate. However, with the helpful guidance from our Scrum Master, the first sprint only encountered some technical obstacles, specifically related to the backend development. This led to us having to delay some of the tasks and hence, backlogs and sprint goals. In our second Sprint, I believe we have now got a good understanding of the Scrum flow and how better self-organise according to the Agile principles and Scrum methodologies.
Daily Scrum
For our daily scrums, the course has set the meetings to just 2 days in a week and we decided those 2 days would be on Tuesdays and Fridays. We utilise Google Meets as our meeting platform and communicate the necessary updates from each of the team members. We have had no difficulties in this process.
Thank you for reading!
— Wilson
References:
