Software is neither self-created nor self-upgraded. However, Software must be developed and maintained by the programmers. That why people established many processes to make software development process easier and more methodical.
Every programmer must understand and master these processes to work effectively. The following article is intended to help programmers as well as students to answer the following questions:
- What is Agile?
- What is Scrum?
- Are Agile and Scrum the same?
- How company’s software development process applied Agile and Scrum?
Software development process:
To better understand Agile, let’s first review the process commonly used for software development. This process usually consists of 5 processes:
- Retrieve customer requirements.
- Development & Implementation.
As the traditional development model (called waterfall), these processes performed sequentially from beginning to end. However, it is difficult to get an exact customer’s requirement at the beginning, because they often do not know what they need until they see the product (software).
When the requirement changes, developers must redo the design and development steps, testing, rewrite the document … At the result, the production does not meet customer requirements. Also, we delayed to develop the product because of over budget.
The history of Agile:
Therefore, in February 2001, 17 prominent figures in the software industry had a meeting to learn how to build lean and effective software.
Manifesto for Agile Software Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to change over following a plan
Characteristics of Agile:
With Agile, we develop software according to iterations (or Sprint) about 2-4 weeks. In each iteration, we fully implement the processes: get requirements, design, code, test, … We built the product gradually so customers can see the product to make a comment or a new requirement.
Incremental and Evolutionary
At the end of the segments, the development team usually produces small pieces of the final product.
This small piece of final product is usually sufficient, runs well, is tested carefully, and can be used immediately (called potentially shippable product increment of functionality).
As time passes from one segment to the next, these runtime pieces accumulate, growing until all customer requirements are met.
Because segments only last for a short period of time, and planning constantly adjusted, changes in the development process (change requirements, technological changes, change of direction). on goals, etc.) can all be met in an appropriate way.
Self-organizing and Cross-functionality
The structure of an agile group is usually Cross-functionality and Self-organizing.
Therefore, these groups make their own assignments of work without relying on hard descriptions of titles.
Self-organizing means each team member has enough competency; Hence, they can be empowered to make self-management decisions and organize their own work to gain the most effective understanding.
Face to face communication
Regarding customer requirements, Agile encourages the development team to talk directly to customers to better understand what customers really need, instead of relying heavily on the type of documentation.
In the development team, Agile appreciates communication between members instead of hard documents, direct talk, face to face will help exchange information more effectively.
The nature of software is changing. All the above help contribute to reducing “Change costs”. However, with the waterfall process, it is difficult for customers to change the requirements after the system is designed. In contrast, with Agile, we develop projects in short iterations so that customers can easily see the finished product, making new requirements at each iteration.
Contrary to Agile, Scrum is not a general principle but a framework, with artifact tools, roles, and processes that are clearly based on Agile principles.
Scrum Activities and Artifacts
This is a summary of a product’s function from the user’s point of view. User stories usually written in a short, simple sentence.
Story Point A unit used to evaluate the effort required to make a user story. The more story point, the bigger the user story and the longer it takes.
Product backlog items initially are features required to meet the product owner’s vision and are prioritized according to business value.
For ongoing product development, the backlog might also contain new features, changes to existing features, defects, technical improvements, and so on.
Constantly evolving artifacts where items can be added, deleted, and revised by the product owner as business conditions change, or as the Scrum team’s understanding of the product grows.
Sprints is the work that performed in iterations or cycles of up to a calendar month.
Timeboxed so they always have a fixed start and end date, and generally they should all be of the same duration.
A new sprint immediately follows the completion of the previous sprint.
Development team reviews the product backlog and determines the highest priority items that the team can realistically accomplish in the upcoming sprint while working at a sustainable pace.
Many teams break down each targeted feature into a set of tasks to form a second backlog known as the sprint backlog.
Finally, Development team provides an estimate (typically in hours) of the effort required to complete each task.
Once sprint planning is complete, the development team performs all the task-level work necessary to get the features “done”.
Nobody tells the development team in what order or how to do the task-level work in the sprint backlog. Team members define their own task-level work and then self-organize in any manner they feel is best for achieving the sprint goal.
Used as an inspection, synchronization, and adaptive daily planning activity that helps a team do its job better.
Everyone understands the big picture of what is occurring, how they are progressing toward the sprint goal, any modifications they want to make to their plans for the upcoming day’s work, and what issues need to be addressed.
Not a problem-solving activity and not a status meeting.
Definition of Done
Whatever the Scrum team agreed to do is really done according to their agreed-upon definition of done.
Definition specifies the degree of confidence that the work completed is of good quality and is potentially shippable.
In fact, we inspect and adapt the product that is being built to achieve the goal of Sprint Review.
Conversation focused on reviewing the just completed features in the context of the overall development effort.
Everyone in attendance gets clear visibility into what is occurring and has an opportunity to help guide the forthcoming development to ensure that the most business-appropriate solution is created.
This is an opportunity to inspect and adapt the process.
Development team, ScrumMaster, and product owner come together to discuss what is and is not working with Scrum and associated technical practices.
At the end of a retrospective, the Scrum team should have identified and committed to a practical number of process improvement actions that will be undertaken by the team in the next sprint.
The single authority responsible for deciding which features and functionality to build and the order in which to build them.
Maintains and communicates to all other participants a clear vision of what the team is trying to achieve.
Moreover, he responsible for the overall success of the solution.
Helps everyone involved understand and embrace the Scrum values, principles, and practices.
Helps the team resolve issues and make improvements to its use of Scrum.
Responsible for protecting the team from outside interference and takes a leadership role in removing impediments that inhibit team productivity (when the individuals themselves cannot reasonably resolve them).
A diverse, cross-functional collection of people who are responsible for designing, building, and testing the desired product. Self-organizes to determine the best way to accomplish the goal set out by the product owner. Typically, five to nine people in size and its members must collectively have all the skills needed to produce good quality, working software.
Sprint Planning Meeting:
This meeting starts each Sprint, lasting about 4 hours. The meeting helps determine the goals to achieve and the work (user stories) to do in the Sprint. During this meeting, the team also estimates the story point for each user story.
During the Sprint, the team will spend about 15 minutes a day to organize a short meeting. This meeting helps members understand the project situation. During the meeting, each member answered 3 questions:
- What did I do yesterday?
- What will I do today?
- Do i have problems and obstacles now?
Sprint Review Meeting:
This meeting takes place after the end of the Sprint. The whole team will review the completed and unfinished work, then demo the completed parts to the Product Owner. Then update the Product Backlog.
During this meeting, the whole team look back and assess what has been and has not been in the last Sprint, and propose improvement measures.
Applying Scrum to Enouvo IT Solutions
Recognize the effectiveness of Scrum in software development. Enouvo IT Solutions has applied Scrum to the management and implementation of our software development projects. The success of the company’s projects demonstrates the efficiency of Scrum. Finally, we are very grateful for the birth of Scrum.
Below are some images of Lastly, there are some images of how we use Scrum in our software development process.
Daily stand-up meetings
Many people often think of Agile and Scrum are the same, but not:
In fact, Agile is not a complete process but only a set of general principles that we should follow to develop software in a effective way.
So, based on Agile principles, proposed software development frameworks or processes such as: Lean, Kanban, XP, Crystal, Scrum.
I hope the article above helps you have a good view of Agile and Scrum.