Agile is an approach to project management that aims always to have a working product while continuously improving in short increments. Instead of delivering a product in the end, as in the case for Waterfall, Agile looks to provide a minimum viable product(MVP) and improve on it iteratively based on customer feedback. Agile is not a management methodology but more of principles and philosophies behind completing projects for customers. For this blog, I will discuss the values of Agile (from Agile Manifesto) as well as a commonly used agile framework, Scrum.
The Agile Manifesto was written in 2001 by tech industry leaders to share insights on project management from their experience. The four values of the Agile Manifesto emphasize certain items more than others. I can find the values here. The manifesto states that even though there is value on the objects on the right, I should prioritize the left items.
The first value emphasizes individuals communicating with each other more than using the tools to force communication. If the tools created to ease communication become a hindrance, then the device is obsolete. What really matters is that the team works together to deliver better products.
The second value emphasizes delivering working software over comprehensive documentation. I should spend more time on bettering the product, and I should spend less time writing or reviewing documents. Documentation is essential, but if it’s hindering customer satisfaction due to a shortage of time, working on the product is more important.
The third value prioritizes customer collaboration over contract negotiation. Since customer satisfaction is the highest priority, agile teams must have the freedom to make quick changes relative to customer wants. If contract negotiations for changes become extended, the increased wait time for product delivery will lower customer satisfaction.
And lastly, in an Agile project, it is crucial to be flexible, change, and adapt to customer needs. Although following a plan is essential, if the project’s rigidness falls behind the project’s changing needs, it’s more important to respond to change.
The most popular framework using an Agile philosophy is called Scrum. Scrum is a technique to deliver and test products in short increments quickly, usually 2–4 weeks, called sprints or iterations. When using Scrum for project management, a small team plans for future sprints meet daily and reviews the deliverable once the iteration is completed.
The objective of using Scrum is to create value for customers iteratively. Each iteration, in time-boxed sprints, aims to improve the product by building smaller chunks on top of each other.
Roles
A Scrum team has three roles: a Product Owner, a Scrum Master, and the Development Team.
The Product Owner’s responsibility is to make sure the team is building a product the customer values. They act as the voice of the customer through their ownership of the Product Backlog. A Product Owner needs to be decisive, flexible, and customer-focused when prioritizing the Product Backlog.
Product Backlog — a prioritized list of work for the development to work on to achieve the project goal.
The Scrum Master helps facilitates team meetings and allows everyone to withhold the scrum framework. Scrum Masters guide/coach the team members on Agile and Scrum practices and maximize the team’s potential by efficiently managing the Product Backlog. A Scrum Master is also responsible for creating Scrum events such as daily stand-ups(daily meetings) and iteration review(at the end of a sprint).
Daily Stand-Ups — 15-minute daily meetings where developers answer three simple questions; What did I work on yesterday? Any roadblocks from yesterday? What am I doing today? In order to compress time by avoiding chit-chat, developers may be asked to stand up and present. (Stand-ups while sitting down tends to last longer.)
Iteration Review — When a sprint is ‘done and a time to present/celebrate the sprint results. The term ‘done’ must be first defined. For example, ‘done’ may be defined as code written, code reviewed, and code tested on a live dev server.
Retrospective —A time after sprint completion where the team reflects on the past sprint experience to improve for the future. It’s an opportunity to find what worked and what didn’t work.
The development team, ranging from 3–10 people, comprises the developers who will build the product. The group should be small enough without being bogged down by too many ideas while large enough to have diverse opinions.
Processes
1The product backlog is the main list of tasks for the project’s life cycle duration and is the first step in the scrum framework. The product backlog is not static; which is to say, stories and epics can be added as needed. The product backlog is maintained by either the Product Owner or Product Manager and is essentially the team’s to-do list.
The items in the product backlog are tasks that I can complete in one sprint cycle. The item should include describing the user story, the rank of importance, time estimates, and acceptance criteria.
I should read the user story’s description with respect to the customer and state actionable deliverables to gain value. A typical template for a user story looks like such:
“As a <user>, I want to <action> so that I can <value>.”
Each story’s rank of importance is determined by either the Product Owner or Product Manager and is relative to the customer’s immediate needs. The entire Scrum team can set the time estimates of each story, and a common form of effort estimation is called story points with Fibonacci sequencing. The idea is to choose a story as an anchor, assign it a point from the Fibonacci sequence, and then assign the remaining tasks with story points relative to the anchor. The exponential nature of the series helps estimate the time for uncertain/risky tasks as people in nature tend to underestimate themselves when time-binning.
The acceptance criteria, created by the Product Owner, contain specific requirements that the customer wants. This can include functional add-on applications, outputting a message returned to the user, text formatting, etc.
2The second step is to plan the upcoming sprint. During sprint planning, the scrum master discusses who will be available for the sprint, the average velocity(number of story points completed in a single sprint), and what I will accomplish items from the Product Backlog. The selected items become the Sprint Backlog for the duration of the sprint. (Duration of sprints are short; usually, 2–4 weeks).
This is also a time to define the meaning of ‘done. The definition of done refers to agreed requirements to pass before a story can be considered complete. (For example, ‘done’ may be defined as code written, code reviewed, QA reviewed, and tested on a live dev server.)
3During the sprint duration, the team meets daily(called stand-ups) where each developer answers the following three questions; What did I work on yesterday? Were there any roadblocks? What will I work on today? If a developer encountered a roadblock, another contributor may chime in and let him/her know they can help after the meeting. Stand-ups shouldn’t last more than 15 minutes. To encourage quicker meetings, developers may be asked to stand before presenting. Having stand-ups while developers are sitting tends to last longer.
4At the closing of the sprint, an Iteration Review is set for the entire scrum team and is a time to discuss which products were completed and which weren’t. The development team needs to celebrate their accomplishments and demonstrate the completed work during the sprint. The iteration Review should last between 30–60 minutes and allows developers to receive and give feedback on each other’s work.
5Lastly, the sprint is closed with a Retrospective meeting where the scrum team meets to reflect on the iteration experience. It’s a time for developers to share what was learned, celebrate things that worked, and work out things that didn’t work. Action steps are developed for areas when things didn’t work by finding creative solutions for the future. The retrospective is a time for the team to reflect on their progress and promote a healthy and honest environment.
