Things I Learned: Agile with Scrum
To start things off, I wasn’t experienced with Agile. Actually, I wasn’t really experienced with proper Agile, as one of my projects was using Scrum-like processes; we used Azure DevOps kanban plus daily ‘standups’ meetings that last hours. Not to mention our ‘PM’ constant pings asking for updates in the middle of a sprint, like it’s a military sitrep or something. I do know and studied the proper way of how it is usually done from my software engineering course, but still, zero proper experience. So my expectations when first attending the PPL course were kinda high (And also because of the fact that PPL is worth 6 credits 😏).
Recalling the Agile manifesto again:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.
Scrum in PPL
I thank the PPL lecturer team for providing a clear hierarchical team, consisting of a Product Owner, a Scrum Master, and 4 other developers working together to create our product.
Backlog
A product backlog is the single source of requirements for any changes to be made to the product.
Formally, this is true. We often contemplate our decisions only to remember that we do have this to refer to. Informally, we do sometimes need to clear things out regarding the requirements written here, so we sometimes ask directly to our product owner. Our backlog contains a list of user stories (product backlog items/PBI), each has its own acceptance criteria.
For a PBI to be accepted, each acceptance criteria from that item need to be implemented and pass acceptance tests done by our product owner.
Sprint Planning
Right after the last sprint retrospective is done, we straight away planned our next sprint. The process itself is quite simple: deciding which backlog items we’re going to work on and splitting them into tasks capable to be done by a person each. For this purpose, we use the Gitlab board, where we can insert new tasks, monitor tasks in progress, and tasks that are considered done (passed the acceptance test).
Standup Meetings
A twice-a-week catching up session arranged by our scrum master with the whole development team. Each of us describes what tasks we have done, what tasks are we going to do until the next standup meeting, and what problems do we encounter while doing our tasks. This usually never took us more than 15 minutes, as problems that are big enough that need to be discussed longer are done outside the standup meeting, hence the name ‘standup’. Nobody wants to stand up for more than 15 minutes, right? 😃
Retrospectives
At the end of each sprint, it is our time to reflect. We need to write out what things we thought work out well during the sprint, and also what things that don’t really work out at all. After that, we put our ideas on ‘experiments/actions’ that will help us tackle the bad things that don’t work out so that our following sprint could be better.
I personally like the way we do it, by writing individual points we want to make on sticky notes and posting it up on a board or some kind.
Back to the manifesto
Individuals and interactions over processes and tools
I get it. All these tools we use (Gitlab board, the fixed backlog on Google Sheets, online retrospective board) do feel like we are violating this principle. It does feel that way in some way, but we then remembered that none of these tools keeps us from interacting with one another. We still regularly do our standups and retrospective via a video conference call (We’ve done face-to-face meetings of course). And in the end, each one of us is trusted in doing the tasks in our own individual way. Feedbacks do come along, but it still fulfills the interaction principle. I do think it is perfectly balanced.
Working software over comprehensive documentation
Imagine writing out documentation on a software that is evolving constantly. By the time our comprehensive docs are written, it will be outdated! Surely by now we know that with scrum, deliverables are prioritized. We won’t let anything delay our backlog items delivered when it’s due.
Yup, that’s also a part of the reason why we’re using Test Driven Development. Tests do validate the routines in our app. And if we do need more validation, that’s where the acceptance test mentioned beforehand also comes into good use.
Customer collaboration over contract negotiation
I feel like, this is the part where our Product Owner really plays his role to fulfill this principle. In our case for TBCare, our PO is the middleman between us the development team, and our stakeholders/customers. We do have sprint reviews, where everyone involved in this project, including our customers from PPTI, join in a conference call and give us direct feedback each sprint.
Then again, I am 100% sure if this project is written on a contract at the beginning and not by direct collaboration during the development, our TBCare app would not properly satisfy our main user group needs: PPTI Officers, as there would be many user-specific use cases and details that we as a development team would not know without being informed, feedbacked, and tested directly by them.
Responding to change over following a plan
This principle is one of the direct outcomes of customer collaboration in our project. They will actively explain the holes in our deliverable, and kindly give us proper feedback and changes we need to do. One of the examples of change done within our project is covered by one of my groupmate involved in our backend development. Check his writing out.
Phew, that’s a lot to cover. I am sure glad I’ve managed to share my agile working experiences with you guys (hehe 😃). That is all for this article, thanks for reading. Cheers!
Written as an assignment for my software development project individual review.
