To be “Agile” in Agile Development
Hearing the “Agile” word sometimes refers to scrum, stand-ups, session plannings, and sprints. More than that, Agile is a whole mindset. Thanks to agile, the need for flexibility and changes in a finished or working product can now be answered. With the capability to manage various changes during the development process, Agile brings promising benefits for your development. It can help the teams work efficiently on the development and get confidence to the stakeholders because the product is regularly tested during the development.
According to Agile Manifesto, the whole idea of agile is because that word represented the adaptiveness and response to change which was so crucial to their approach. It’s all about thinking through how you can understand the environment, face the uncertainty, and adapt to everything going along.
There are four main values of Agile to be concerned :
- individuals and interactions over processes and tools;
- working software over comprehensive documentation;
- customer collaboration over contract negotiation; and
- responding to change over following a plan
Speaking of these values, here’s a brief example of how my team applied the four core values of the Agile Manifesto.
Individuals and interactions over processes and tools
People are the ones who run the development process. Hence, any development process should be valued above processes and tools. In my team, we applied this value in communicating on the working process rather than sticking to a specific tool or process.
Working software over comprehensive documentation
Though we have several documents to be done, agile forces us to be managing changes during software development. Thus, we build several documents such as a PRD and PBI only for initial guidance to the development. Any changes on the software prioritize working software over the change in documentation.
Customer collaboration over contract negotiation
In Agile development, the customer is involved throughout the whole process of development instead only in the contract. Any working software will be discussed with the customer does that fits the customer’s needs and wants. My team applied these values by regularly discussing the current working software with the client and asked if there was any feedback they could give or if there were any changes from the proposed specifications.
Responding to change over following a plan
Agile manage us to be ready for various changes during the development process. Thus, we have to be prepared for any changes from customer feedback or the needs of the used tools. In my team, we are responding to modifications in many ways. It can be rearranging the priority, adding some new functionality, or changing the business flow if needed.
With the concepts of agile being said, the next question is, what are things me and my team do to be “agile” during this agile development? Agile software development mostly runs in a cycle of 6 parts: concept, design, development, testing, deployment, and review. While agile itself has several types, such as Scrum, XP, Lean Software, etc., these all types run the same cycle. Here’s a brief story, of how my team doing this cycle in our software development.
As we work in scrum methodology, we have 2 important roles in our team. The first is the Product Owner, someone who’s in charge of making sure any client requirements are met. And the scrum master who’s in order to make sure the development cycle goes well. Before going through, shout out to the product owner and scrum master of team La Casa De PPL.
Back to the software development cycle, the iterative cycle from concept through review is done in an amount of time called sprint. In our case, every sprint was held for three weeks, with four sprints for the whole development.
Start with concept and design phase. We start every sprint with an agenda called sprint planning. This session is where we will determine what we will do in the whole sprint, what things we want to achieve during the sprints as the implementation of concept phase, estimate how much time we need to complete the tasks, and arrange tasks priority for the design phase. This session is lead by the scrum master with the whole scrum team.
The next is development and testing. Since we apply TDD in our product, these phases were done iteratively. The development phase can be called as the central part of the whole development. This phase is where we actually ‘develop’ the development! The testing part aims to ensure we have met the requirements we had built earlier. (Anyway, you can see my blog about TDD here!)
The next is deployment! This part is when we can finally serve the deliverable product of our development. In this phase, the client can evaluate our product thoroughly, and those feedbacks will be raised in the last phase, review!
As sprint planning is to look ahead a sprint, the sprint review is now the time to take a look back! In sprint review, we will evaluate what things we have done during the sprint and see if there any (well, there will always be) evaluation during the last sprint.
After all, I can’t say I am “Agile” enough (I still have a lot to learn), but I just can’t picture how to run with not being agile and not being in agile software development. Thanks to agile, my team and I work in harmony, and so far, we are proud of the result we’ve delivered. We might not “Agile” enough, but at least, we survived! 😜
