Agile Manifesto
The team worked in an agile environment — a time boxed, iterative approach to software delivery that builds software incrementally from scratch. It was my first experience working in an agile environment with such a big team of about 35 people consisting of Scrum Master, Project Managers, In-House Developers, External Developers, Business Analysts, Designers and etc. Humble to be learning new things from everyone.
In the agile environment, things move really fast. Velocity places a key factor in the project, given limited time and resources to deliver the expectations of the product. At some point in time, the requirements given by various Product Owners may be subjected to change. Therefore, the agile process is flexible enough to cater for a change in requirements. With that change, product features will have to be re-prioritised and efforts will have to be re-estimated. Even though the risk of uncertainty is always present, knowing how to prioritise the more important product features and allocating available resources to it can minimise that risk.
Scrum is a type of agile methodology, which is popularly used in the development of an IT project. Kanban is another type of agile methodology used for the maintenance of a project. Often, agile software development methodology values:
- Individual and Interactions over Process and Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiations
- Responding to Change over Following a Plan
More importantly, scrum focuses on the team — people value.
Scrum project make progress in a series of sprints. Each sprint is time-boxed over a two-week period. Not too long, nor too short. The team used softwares such as Trello, Confluence, JIRA, to manage the project and track workflow. Developers usually do pair programming boost efficiency. It is slightly unusual for In-House Developers to be working with External Developers, for theory states that software development is done either in-house or outsourced. However, this project is a special case and the team is rushing for a deadline.
The scrum framework is broken down into the following:
1. Roles
- Product Owner — voice of stakeholders and customers
- Scrum Master — servant leader to the team, responsible for enacting scrum value and practices
- Team— co-located or cross-functional (programmers, testers, user experience designers, etc)
2. Ceremonies
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Sprint Planning
“If you fail to plan, you plan to fail,” quoted by Benjamin Franklin.
Sprint planning is very important because it is very disruptive to break the sprint in the middle with changes.
Before the start of a new sprint, Business Analysts, Designers and Developers will sit in for sprint planning. Everyone working in the team will definitely be involved. Business Analyst will present the business logic and requirements of each product feature, together with the screens designed by UI / UX Designers. Subsequently, the feature will be broken down smaller tasks, which can be measurable in terms of time completion. For each task, all developers would estimate the effort needed to complete it. The effort was measured in size S, M, L and XL. Size S effort typically took about half a day to a day maximum. Each developer will be given 4 cards of different sizes, from size S to XL. After the Business Analyst has gone through a task, each developer will estimate the effort by raising a card. Ultimately, a consensus of the effort will be agreed upon all developers and then recorded.
Daily Scrum
Every morning, the team will conduct a Daily Scrum (Stand Up) to review the work progress. It is a relatively 10 to 15 mins session whereby everyone in the team would gather and update the following:
- In Analysis
- Ready for Sprint
- Sprint Backlog
- In Progress
- Ready for Test
- Testing
- Done
Sprint Review
At the end of each sprint, the team presents what is accomplished during sprint. It can take the form of an informal demonstration of features/architecture. Showcase Stars will walkthrough the working functionalities of the product and ensure that everyone in the team had a common understanding of the product. During the walkthrough, the product is tested on both Android and IOS phone simultaneously. At one glance, we can see the subtle differences in the design of the product on each phone.
Retrospective
Retrospective is a short session conducted after the sprint review to seek suggestions from team members on what can be improved on, what should not be continued, compliments to other members, and etc. Good stuff can help the team sail forward with the wind. Bad stuff will drag the whole team down, just like an anchor.
3. Artefacts
- Product Backlog — a list of all desired work on the project prioritised by product owner
- Sprint Backlog — a list of tasks and tickets to do for each sprint
- Scrum Board
