The Agile Scrum framework entails five steps: visioning, planning, sprint, shipping and retrospective

Agile project management differs from traditional methods for its emphasis on the short feedback loops and adaptive cycles. By constantly releasing increments, advocates believe the Agile process is more adaptive to customer value and need.

It was first introduced in the 1990s to replace the heavyweight waterfall methodologies. The early 2000s witnessed a milestone to Agile methods. As ten prestigious practitioners, including Jeff Sutherland, co-presented the famous Manifesto for Agile Software Development.

Since then, many work practices have evolved. Scrum, Extreme Programming (XP), Feature-Driven-Development (FDD), and Test-Drive-Development (TDD) are just a few of those. However, no matter what they change, the essential principles stay the same, to “de-risk” the business by iterative development, shortened feedback loops, and adaptive planning.

Among all those frameworks, Scrum is the most popular. One complete cycle entails five stages: visioning, sprint planning meeting, daily sprint, shipping, and retrospective.

/This guide is about what is and how to set up Agile. For our guide of using XMind for traditional project management, check out this post./

Scrum vs. Kanban

Before the guide, let’s clarify two commonly used terminologies:

Scrum. An Agile framework designed for small teams to break their work into actions that can be completed within timeboxed iterations, called sprints, commonly two weeks. The team track progress and re-plan in 15-minute stand-up meetings, called daily scrums.

Kanban. A lean method to manage and improve work, by visualizing work items to give participants an overview of demands and available capacity. The collections of visualized items are called Kanban Board. The board is also utilized in Scrum.

Kanban and Scrum are two methods. But for the prevalence and effectiveness of Kanban Board, the Scrum frameworks sometimes adopt this tool as well. Apart from terminologies above, you can also check more Agile Glossary in AgileAlliance.

Step 1: Preparing – Build your team

Typically an Agile team consists of three roles: the Scrum Master (SM), the Product Owner (PO) and the developers. The team size is around 7+/-2—1 Scrum Master, 1 Product Owner, and 4-5 developers.

SM is on the developer side to make sure the project goes smoothly, and hopefully quicker. (S)He should be a mediator or facilitator as a standalone role.

However, based on the team interest, the tech lead or QA works well as a part-time Scrum Master. PO is on the project and user side. PO is the business people and customer representatives. Consequently, Product Owners are often product managers or marketers.

Keep in mind – Collaborate but not compete

Scrum Master and Product Owner have a different focus and can go into serious conflicts. But remember, teamwork should achieve things collaboratively.

The purpose of having three roles is to make the team full-functioning. That explains why everyone within the team plans together.

Step 2: Visioning – Prepare the product backlog

PO is the primary drive at this stage. S(he) talks to stakeholders and synthesizes a product feature backlog. Stakeholders usually include the executives, the sales and support team, the marketing team, users or customers. The PO has to groom the backlog and to prioritize the features. And from this giant backlog, the Product Owner articulates visions and following goals.

Keep in mind – Automate the laborious process

Feeding the product backlog is sometimes a tedious job. Collecting and tracking procedures can be highly repetitive. For bug fixing, the PO can connect the backlog with a bug-tracking system. Comment tracking tools and a social media management platform are also helpful.

Step 3: Meeting – Hold the sprint planning meeting

The meeting brings forward clear sprint goals and sprint backlogs. It usually lasts for less than an hour and happens early at the sprint week(s). Based on product goals and product backlogs, the team works together on splitting backlogs into shippable increments.

Developers decide the appropriate number of story points, the way to break down the goal into tasks and hence the sprint backlog. At the end of the meeting, the team should be confident on the scope and desired deliverables of this sprint.

Keep in mind – Don’t forget the sprint goal

The sprint goal is just one or two sentences, but communicating the expectation on deliverables. It works as a quick report for stakeholders about what the team is doing. A clear sprint goal paves the way for measuring the performance of the delivery.

Step 4: Daily Scrum – Check along the way

Daily scrum (daily stand-up) meeting is for project status updates. It is best to arrange the meeting at the same time and in the same place every day during the iteration.

The daily stand-up demonstrates Agile’s focus on face-to-face communications. Scrum Master should address the impediments to facilitate the development process. If there is anything severely affecting the sprint goal, the Product Owner has every right to know it at once. In return, PO withholds the temptation of changing the sprint backlog.

Keep in mind – Short and concise

The stand-up should be no more than 15 minutes. Notice that the meeting is like information sync within the team, rather than problem-solving. It is better to leave the problem-solving in other processes.

Step 5: Shipping – Release and Retro

The release of the team is demonstrated at the end of the iteration. Stakeholders, inside or outside the organization are in the review meeting. By comparing the overall sprint goal with the achievements, the Product Owner can measure how successful the sprint is.

After the review meeting, the Agile team holds a retrospective meeting to reflect on what should be improved and what should be continued. For novice developers, it is also a perfect time to revise the expectation of velocity and capacity.

Keep in mind – Never skip the retro

Even if nothing goes wrong, the team should never skip the retrospective. Confirming what is right alone is helpful to future sprints. If the Scrum Master wants, (s)he can even launch a vote for improvement proposals.

Pitfalls and criticism

Advocates claim that Agile practices are a balance between micro-management and no-management. However, critics arise from the experience of adoption. Some empirical studies have found no scientific evidence for the agility of the team.

As agile emphasizes flexibility, it takes a toll on continuous quality control. The shortened project length implies acting quick and lean. That often comes with a lack of proper documentation and resources. Projects tend to lack continuity and integrity, making the principle of quality focus almost obsolete.

Agile is not suitable for highly risk-averse organizations or industries, say, pharmaceutical. These long-established industries have their clunky, yet important conventions to follow. Changing procedures against traditional management is extremely risky, if not dangerous.

That being said, countless successful examples are evidence that Agile works. Although there are pitfalls, the ever-evolving Agile frameworks provide tools and techniques, say continuous integration, automated unit testing, and code refactoring, to at least remediate the problems.

Key takeaway

Agile process advocates fast iterations, continuous improvement, and rapid response to change.

It mainly consists of five steps: visioning, sprint planning, daily scrum, shipping, and retrospective. Agile aims to balance between micromanaging and loose management. Although it lacks strong evidence for productivity, the Agile process is arguably best practice throughout the IT industry.

How about your opinions? Please share with us your lessons and tricks in applying Agile methods :).