Agile, An Answer For Everchanging Industry
“Intelligence is the ability to adapt to change.”
Stephen Hawking
Nowadays, industry is a very unstable world. How many times you was asked by the client for a change in requirements, even thought its not the time for it in your process models? A lot? I have experienced it too. So, whose fault is it? Is it your client/business team fault for not research the requirements needed? Your fault for not developing it fast enough? Or even this industry itself is the problem? Well, as wise man said, blaming will not change a thing instead, come with a solution. And here comes agile, as our solution, hero, and protagonist.
What is Agile?
Agile is a methodology in software development where we focused ourselves in delivering a product through series of small delivery, and workflows that are more resistant to changes in requirements or anything related to its development. As Robert Bunning said that “Agile is a pioneer in more dynamic and humane industry environment”, it is encouraging every people that are part of it to participate actively and give his/her thoughts, instead of just doing what they were being told to do. Unlike plan-driven approach, like waterfall (Most of us using this in our daily life), where we treat each part of process model as a separate part which need to be visited when we have changes, agile consider it as 1 part in implementation, merging them with design and implementation in the process (Of course, as long as the changes are not too big, of course :)).
Agile Manifesto
Agile is not a just commonly used term, it originates from a group of developers that includes senior programmer such as Robert.C.Martin, Kent Beck, and many others. After thinking what is the best for software development in the industry, they came up with these manifestos:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation. After all, the most important part in our software dev is a usable product, isn’t it?
- Customer collaboration over contract negotiation. Agile wants customer to be involved in the process of software development, making changes in requirements, checking it in a given time (once in 1/2 weeks) instead of just giving the requirements and involved again at the end of process.
- Responding to change over following a plan. This is what agile answer to current rapid Industry, it embrace changes as part of it, instead of being haunted with it.
These manifestos, will be defined more detail in Agile principles, along with my practice for them.
Agile Principles
Taken after those manifestos, a principle was born, designed to gave more technical explanation about what those manifestos expect us to do. This principle, whatever our agile framework that we choose must taken into consideration. I will also give an example about it from my software development (PPL) project in my university.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. In my project, these was done with a Scrum methodology which I will elaborate further, by delivering part of its product once in 2 weeks time. This allow us to prioritize more important part of the product first and getting a feedback for it, allowing us to make little small changes in the product, compare to many small changes or even big changes when we deliver our final product.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Sometimes, a better idea from the client just pop in when the development already started. Unlike any other process models that require client to wait until the end of process, thus, going back into requirements gathering step, Agile allows client to tell the developer in the middle of software development. Developers, could estimate how big the changes is and saved it for the next agile cycle if they deemed it was too big. An example of this in my project is when our client asked us to add 2 new features, a dropdown and direct link feature. We estimated that dropdown feature is essential for this product and wasn’t too big, so we include them in the middle of our development. Meanwhile, we feel that direct link feature wasn’t very important considering other features, and it is too big for us to include in our development. So, we asked them to include it as a notes in the next development.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. As I mentioned above, this was done by creating a time frame (2 weeks in my case) in which we were expected to implement some features of the software.
- Business people and developers must work together daily throughout the project. This was one of the most essential part in agile, by making them closer, a software can be tuned accordingly to meet its current demand. My product owner for my PPL project is heavily involved. We frequently ask her asynchronously via social media, or even asked her to join our video meetings to explain certain requirements further. By doing this, we minimize the risk of miscommunication that more often than not creep in as the software become bigger.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. This is an obvious one, isn’t it?
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. A face to face conversation is an important one even in the midst of this global pandemic. Even when we can not meet face to face, we frequently having a video meetings every 3 days where we convey information (our works, struggles, and plans) in those meetings.
- Working software is the primary measure of progress. In my project, we have acceptance criteria for each feature, explaining in detail what is considered as working feature or not. We are examined by this criteria that has been defined by our product owner. No matter how well documented or how nice our code looks like, if we did not met acceptance criteria, our software would be consider as a failure and we must do it again to meet its criteria.
- 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. With these changes that can occur at any given moment, a good code and good design certainly will help us. By creating a good design, we can make changes that related to that features only, instead of changing nearly every features just because one feature (This is a nightmare). In my software development projects, even though we just started this project, we implement a good design by creating good file structures. This is an example of our project structure in react.
- Simplicity–the art of maximizing the amount of work not done–is essential. I do think that this is self explanatory, and I will not elaborate this further.
- The best architectures, requirements, and designs emerge from self-organizing teams. Self organizing team is a team that work with these values: Teamwork and collaboration, Competency, Continuous improvement and growth, Respect and trust in the team, and Ownership. Unlike any other teams, these teams do not wait for their manager to work. They usually identify which job need to be done and work accordingly. An example of it in my project is our backlog requirements. Generated from our product owner, we estimate amount of work to do for these backlogs and took works that we thought are the most essential for us.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. These reflections were usually done at the of of our process model (or sprint should I say?). For my project, at the end of every sprint, we will give feedback to each other and trying to solve problems that emerges when we did our sprint process. Just like people said, even a donkey does not fall into the same hole twice! :D
As I said above, agile is just a methodology. These methodology, are not applicable in our software development process without a framework that we built our development upon. There are many agile frameworks out there such as Extreme Programming (XP), Crystal, and Scrum. For the sake of simplicity of this writings, I will only talk about Scrum and how do my team apply it in our project.
Scrum Methodology and its application
Scrum is an agile framework that is commonly used in tech teams/companies. It is mainly used because of how adaptive it was and it has the most acceptable amount of time (not as fast as 2 weeks full software delivery nor as long as 6 months full software delivery). In Scrum framework, there are 3 important peoples that must take parts in the process:
- Product Owner, the client himself or someone who is trusted by the client to be their middle brige between us, developers and the clients.
- Scrum Master, Someone who had experienced Scrum and having a good understanding of it. He is tasked to mentor developer team, ensuring that they do it in scrum way.
- Developer, Of course, they will be the one who develop the product.
Scrum methodology consist of these steps:
- Product Backlog. I like to refer it as a requirements gathering in a sophisticated way where we gather requirements from client, and grouping them into backlog (A feature with specific goal and criteria). In my project, these was done by my product owner and we, as developer, are asked to give feedback about it.
- Sprint Planning. This is the place where we create a plan of our sprint. These include how much work we need to do, which feature (not backlog) we will prioritize first, and how do we divide our task. In my project, we decide to split our teams into frontend and backend x devops engineer. We also estimate that 2 features, that consist of around 6–8 backlogs are the most we can do in one sprint cycle.
- Sprint Backlog. According to my experience, this is the place where we gave a value for each backlog that indicates the difficulty of each backlog. There are several ways to do it, such as bucket system, affinity system, etc. The one that we use is fibonacci values, where a small value indicate that this backlog does not require much amount of time.
- Sprint Started! Our sprint started for two weeks, most of the guide and book I know indicate that an ideal sprint time is ranged between 1 week -1 month. We choose two weeks because we feel that 1 week is too short to accomplish anything drastic.
- Daily Scrum. Everyday, scrum team is expected to meet and convey information to each other. It includes works, future works, and their struggles. In my team, we change our daily scrum to 3-day interval daily scrum, where we met every 3 day. These was done because of small amount of time we had, especially considering we have another class to attend.
- Sprint Review. Sprint review is the place where we met our client/product owner where we report the development of our working software to them. We start our review at the end of our sprint and let our client/product owner examined our software products.
- Sprint Retrospective. The final step before the start of a new sprint iterative, we evaluate ourselves and finding solutions for all problems that occur in our sprint.
At last, we met the end of this writings. We have talked a lot about Agile principles, and Scrum methodology that inherits agile as its core value. After reading a whole topic about it, it is time for you to try it yourself! Just say good bye to a non adaptive and painful process models, and say hello to you friends, agile and scrum! Cheers!
References:
