Agile is the most frequent word I see when learning about modern software engineering. This word refers to Agile development that specializes at responding to changes in order to satisfy needs in rapid pace. But, in some articles/guides, Agile Development is only a set procedures created to rapidly get features done. We should (or must) learn the principles of Agile from it’s reference, Agile Manifesto.
What is Agile Manifesto
Before the manifesto, there are various agile principles (such as extreme programming, pair programming, etc) created from the 1970s. In early 2001, a group of 17 developers created the manifesto in 2 meetings on Oregon and Snowbird, Utah. The explosion of personal computers creates huge demands and significant changes. The lag of time in developing software to fulfill needs creates frustation with the tradtional methodology of the 1990s. The manifesto is created to encourage developers to speed up processes and work on practices that focuses more directly to the users.
The values of Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Twelve principles of Agile Manifesto in short sentence:
- Early and continuous delivery
- Change for competitive advantage
- Deliver working software frequently
- Business and development team working together
- Support team members
- Face-to-face conversation to convey information quickly
- Working software as measure of progress
- Maintain constant pace for sustainable development
- Technical exellence and good design
- Simplicity
- Self-organizing teams
- Reflection at regular intervals
The Twelve principles of Agile Manifesto largely taught about developer should be able to accept changes and create deliverables on quick pace. This means that developer should work closely with the stakeholders in order to quickly deliver a working feature for efficency and competitive advantage. The principles also needs a regular reflection on how to become more effective and adjusts its behaviour to conform with the reflection.
How Scrum is Created to be Agile
The scrum process is drawn in different and sometimes large graphs. But they share the common ideas on mechanism and meetings. Here is the common example of it.
Product Backlog
Product Owner is responsible to create product backlogs in scrum process. This product backlogs could be added later after a sprint is done.
Sprint Planning
In Sprint Planning, the team gather to sort the backlogs of the effort required and decide what to work on in the beginning. This generates a sprint backlog, the tasks targetted to be done at the end of the sprint.
Sprint
On the Sprint, a regular meeting is set to address teams completion, next tasks, and its impedance. From the regular meeting, product owner could adjust the sprint backlog and assign the backlog to the member who has finished previous backlog. Aside from that, the team needs to be working on the implementation so that the aim of the sprint is completed.
Review and Retrospective
Once a sprint is finish, either the aims are fulfilled or not, the team gather for a review. In the review, the team needs to evaluate and plan an improvement on the next sprint. The sprint backlog that hasn’t been finished will be carried on next sprint.
Repeat
The work is then repeated indefinitely. The team grows and adapts to the scrum as member joins or leaves over time.
Alternative of Scrum (Scrumban)
Despite the agility of scrum, there are some objections to scrum as an agile development framework:
- Strict rules of meetings and sprint
- Meetings that could take longer time
- Fixed length of sprint
- etc
There is a hybrid Scrum that could address those issues called Scrumban. This framework utilizes a board called kanban to organize tasks/backlogs to be work and done.
The purpose of this kanban is to provide the best next thing to work on by the team. The daily meeting is kept and could be done asynchronously. Instead of planning and retrospective, scrumban only needs a meeting to address the tasks on the kanban. It’s easier and more adaptable for new joiners to work on the team.
The decision whether the team should use Scrumban instead is up to the team preferences. These are frameworks to apply and adapt with agile principles in mind.
Conclusion
Scrum framework should be executed with agile principles in mind. The agility of the team depends on how quick the development and how open they are to quick changes.