Agile Development in a Nutshell
Agile is a term which means “able to move quickly and easily” in English. But in Indonesian it could be pronounced as “A… gile”, which means “This is insane” in English. Somehow the second term feels more familiar among developers regarding of how many memes have been created on the internet.
In software development, being Agile means being easily adapt to any changes in requirements. That’s why, Agile methods are very suitable for product developments where multiple variants are required or where you find the requirements are very dynamic.
Why is it even exist… what’s wrong with the traditional methodologies?
“We were looking for something that was more timely and responsive” — Jon Kern
Back then, long before Agile development (and also me) exists in early 1990, Software development faced a crisis as PC computing began to proliferate in the enterprise. A variety of different software development started to rise, each having its own set of ideas. However, they had overlapping approaches in common; collaboration, frequent delivery, self-organizing, innovative ways to create. The Agile Manifesto then resulted from this overlaps (and also the frustration of Jon Kern) in the agreement of 17 authors in 2001 (https://agilemanifesto.org/).
The Agile Manifesto stated four core values:
- Individuals and interactions over processes and tools: Agile focuses on individuals involved in the development and its interactions. This will make sure the product will be delivered according to the client’s wishes.
- Working software over comprehensive documentation: Agile values more getting back feedback from client than a full documentation client can’t see.
- Customer collaboration over contract negotiation: A two-way interaction is valued more than just a negotiation. This will make sure both developers and client are benefited. Client will get the products as he wishes and developers will get more evident on the requirements.
- Responding to change over following a plan: Changes may happen due to customer feedback over the delivered product, Agile will value more the changes happened due to the feedback than following the first plan.
Agile principles also come up after the agile manifesto as written on the images above. These principles is becoming a guidance to be agile..
The Characteristics of Agile Projects
Agile process divide tasks into small increments, thus lead to less process planning. It is meant for short term projects with an effort of team work. Agile development is an iterative process in which changes can be made according to the “businessman” satisfaction. The Agile Manifesto has derived these characteristics to the agile development :
- Iterative : focus on single requirement with multiple iteration
- Modularity : decompose the system into pieces
- Time Boxing : it requires limit of time
- Parsimony : mitigate risks and achieve the goals by minimal number of modules
- Incremental : it is developed in increments
- Adaptive : allows changes and adapting in the real time requirements
- Convergent : associated with each increment
- Collaborative : it also needs good communication
- People Oriented : customer satisfaction is first priority
To Agility, and beyond…
How to be agile in software development ?
There are so many frameworks that were born from the agile principles. All the frameworks follow the same agile philosophy, features, and procedures. But it can be distinguished from one another from its implementation point of view. I want to share my experience in PPL about using one of the most preferred framework ; SCRUM.
The Scrum
Simple framework. Easy-to-understand. Tricky to master
Scrum is a simple framework, effective for team collaboration on complex projects. It is simple and easy to understand as the framework has been defined very clearly to overcome any cases where we need to be agile.
Regardless its simpleness, scrum is very hard to master. That’s why we usually need a Scrum Master. This master will make sure all understand about Scrum. And yess… in PPL, my team also have a Scrum Master! He makes sure the team works well under the Scrum circumstance. Also more than that, he makes sure the team stays in positive aura under all PPL tasks. Let me introduce you to my Scrum Master!!
In case to be agile, the team in scrum must be self-organizing. The scrum master is present to bring the team to be agile, but individuals itself must organize his everything to complete the tasks given. The individuals must respect the scrum values as a self-organizing individuals which follows the agile principle.
Scrum In practice
Yess… Agile and Scrum seems very cool this far. More amazingly, in Scrum, we need a set of processes and things we should prepare. Yess.. we need an amazing process and things to get an amazing result. Here we aree…
The Things to be prepared : Scrum artifacts
Surprisingly, there are few artifacts the Scrum needs in the development. Without these things, how can we even start the Scrum… (based on : https://www.scrumguides.org/download.html)
- The Product Backlog (PB)
PB defines ordered list of everything needed in the product like a list of features or requirements.In defining a PB, the product owner will organize each of the user stories into a many lists of prioritized features to be done. So the development will be based on the product owner’s priority as agile should be.
In PPL, my product owner defines PB complete with priority, user story, and acceptance criteria. So my team will understand what requirements should be done or completed in specified PB.
- The Sprint Backlog
Sprint Backlog is a more detailed document containing information about which feature/requirement the team is going and is broken down into tasks. So here… take a peek on my team’s Sprint Backlog.
So in this iteration, my team set PB : Login SSO as our Sprint Backlog which is current running PB. It is broken down into tasks and distributed among the team. Everyone in the team will be self-organizing in doing the tasks, starting from taking his own the tasks, set his own deadlines, making sure his work is done, etc.
- Increment
Increment is the sum of all The PB items completed and the value of the increments before. Before we could build the increment, we should define the definition of “Done” which will be references for the team. For example, here in our Sprint 1, we have increment in PB : CRUD Pengumuman that is added to our current product in staging.
The Process
Scrum Process is a set of sequential events, ceremonies, and meetings that scrum teams perform on a regular basis based on agile principles. Scrum is conducted in sets of iteration, which ideally two to four weeks, which is called “Sprint”. The Sprint makes sure the product will be delivered frequently to the product owner which is one of the agile principles. And as time-boxing is important, it is required to immediately start a new sprint after the previous sprint in defined time period (NO TOLERANCE!!).
- Sprint Planning
Sprint Planning is an events in which team will be gathered to define “What to do next?” for the next Sprint. Everyone involved in the Sprint participates in this event to keep the collaboration and work together. Here we filled the Scrum Board (A board that will be used to attach our tasks).
Sprint Planning does not have to be done face-to-face. But most importantly the plan must welcome changing requirement from product owner’s feedback, and that’s one of how to be agile…
- Daily Scrum
Daily Scrum is 15-minutes time-boxed event for the Development Team to inspect the work since last Daily Scrum. Agile principle is implemented here as the event will keep the developers team in touch through short conversations and let developers know what problems their teams are facing. It helps the developers work together in an efficient and effective way.
For example, in every Daily Scrum, my team will gather and answer some format questions briefly. Our Daily Scrum never exceed an half hour, except there are things to be discussed about (ex: Corona Virus). Yes it should be done briefly, so it will not shorten our coding time.
- Sprint Review
Sprint Review is held at the end of the Sprint to inspect the increment and adapt with the Product Backlog if needed. The result of Sprint Review is a revised PB that defines the probable PB items for the next Sprint.
This is where Scrum shows that product owner is always highest priority. The acceptance of the work in one Sprint will be decided by the product owner. Changes in requirements are also much likely to happen here if the product owner says so, this is where we need to be agile for the next sprint. After the product owner see the result, they may come up with an idea to create another requirements or change the current requirement.
This is the most important moment, the moment the team will come to meet the product owner with a state of waking up after drinking 3 cups of coffee. Noo.. that’s not always like that, but if your team become such deadliner people, that will happen. So make sure your team prepare your products early!
- Sprint Retrospective
It is an event to accelerate our team’s performance for the next Sprint. You might get blamed, or blame people (astaghfirullah), or no blame will happen. But the point is that, in Sprint Retro, the team will gather to communicate the real-life-problems reflection (I don’t really sure how to describe it) regarding the previous Sprint. This event will likely to build reflection and motivation around individuals to keep the individuals in agile condition.
For example, in my last sprint retro, we communicated what are the happy, the sad about our Sprint and also if I could turn back time, what will I do for the Sprint. It is a sad time for me, because this is the time I realize every inch of faults I have made in the Sprint.
Scrum In Practice : Behind the Scene
Those are me and my team experiences in developing with Scrum. But behind this amazing experience, we faces a lot of difficulty in working with it. Starting from the frustration of changing requirements, not efficient Daily Scrum, and also bad result Sprint Review.
But yess, the core of the Scrum is not only the development of the product, but also the development of the team. So looking forward to see the development of me and myself after this development end!
